incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandeep Tata <sandeep.t...@gmail.com>
Subject Re: working together
Date Wed, 08 Apr 2009 23:42:06 GMT
Johan, the wiki pages are great! I think they will help iron out our
process for contributing and committing.

(I added a pointer to the formatting conventions in HowToContribute ,
can't think of anything else to add)

>
> http://cwiki.apache.org/confluence/display/CSDR/HowToContribute
> http://cwiki.apache.org/confluence/display/CSDR/HowToCommit
> http://cwiki.apache.org/confluence/display/CSDR/HowToRelease
>
> A short summary and description of why these points make sense:
> * "Patch-only" evolution of code, attached to a jira issue
> * At least one +1 on each issue before it can be committed, -1 stops the
> patch.
>
> Those two points would make sure that if someone disagrees with a
> change, a refactoring etc, they have a chance to voice their opinion and
> steer it into the right direction.
>
>
> * Trunk is not considered stable, but must pass unit tests
> * Any non trivial change should include unit tests
> * When a branch is created to prepare for a release extra effort is put
> into QA to make sure the release is as stable as possible. Point
> releases would then go out to fix issues found after the release was done.
> * Once a release has been out for a while and people are using it in
> production without problems it is upgraded to "stable" status.
>
> The purpose of these points is to encourage a "vibrant codebase", to not
> be afraid of for example refactoring if it improves the code readability
> or testability. I appreciate that Cassandra is a complex system and that
> changes might have unwanted side effects, but hopefully adding tests and
> code reviews will reduce those. As a final catch-all the release
> candidate and "stable release" process should help end users avoid bugs.
>
>
> Thoughts on the wiki pages? Do they help resolve some of the problems?
>
> /Johan
>
> Sandeep Tata wrote:
>> Thoughts inline:
>>
>>> So the problems I am seeing are:
>>>
>>> 1. We elected a committer without real community consensus. The
>>> barrier of entry was unnatural low on this one. On the other hand we
>>> need non-FB committers for the graduation. The more the better. (No
>>> reason for low entry barrier though!)
>>
>> I think everyone (including the FB guys) agree that Jonathan has been
>> working hard to help move the codebase forward. He has been quick to
>> revert changes that broke the code that the FB guys had in the
>> pipeline and have committed since. I think much of the friction comes
>> from not having a process, which takes us to Torsten's #2:
>>
>>> 2. A missing definition of development process:
>>>  - What is considered a valid code review?
>>>  - How much are changes discussed up-front?
>>>  - What is the roadmap? ...for whom? (weighted as a community)
>>
>> This is probably where we need most work. Here are some simple suggestions:
>>
>> a) I'm a fan of a "patch-only" evolution of code. All changes come
>> from patches, and no changes come from anywhere else (eg. the
>> committers IDE). Even if it is something as simple as cleaning up
>> comments or changing a variable name.
>> b) A patch gets applied if at least one reviewer +1s it, and no one -1s it.
>> c) A patch should pass all unit tests. Any significant patch should
>> come with additional unit tests.
>>
>> Some of this, of course, will mean "more work" for the committers.
>> Sure, but such processes are essential if the project is to grow
>> beyond a small group of core contributors.
>>
>>> 3. Is trunk considered "stable"? Or aren't we missing a stable branch
>>> for the required stability? Once we have the separation between stable
>>> and trunk: Will patches really find it's way from trunk into stable?
>>> Is Facebook OK with that approach. Will everyone cope with the
>>> additional work of merging? Would it be useful ...or overkill to use
>>> merge tracking?
>>
>> I agree with Matt. Trunk should pass build + tests, but should not be
>> trusted for production. I think 0.2 was supposed to be a stable
>> branch. Avinash, Prashant -- what are your thoughts on this? Are you
>> guys comfortable with this approach? Do you foresee any problems?
>>
>> Basically, use a "release" branch for production. The release branches
>> only admit stability patches. New feature and cleanup patches go to
>> trunk. Folks running Cassandra in production only need to be nervous
>> when moving from one release to next, and not worry too much about
>> every single patch breaking their running system.
>>
>>> 4. Real world testing feedback is not publicly available. So the
>>> feedback on changes will only slowly reach the community. This is not
>>> easy for a project like this. But is there a faster way to provide
>>> testing feedback? (IIRC Yahoo was providing testing feedback for
>>> Hadoop. They even try to auto-apply patches from JIRA)
>>
>> With time, FB may be able to provide feedback from their "divert some
>> traffic to the new version" system. Auto-applying patches from JIRA
>> sounds a little ambitious right now :-)
>>
>>> 5. Is there really no code ownership issue. Working on a code base for
>>> 1-2 years can get you attached to the code you have written. Can
>>> everyone really let go? Is it OK if someone else really just rewrites
>>> parts of what you wrote? (No, it doesn't mean the original code was
>>> bad! But maybe with the new code it is more readable ...
>>> understandable - especially for someone who hasn't spent the past
>>> years working on that code) Is there room for refactoring?
>>
>> :-)
>>
>>
>>> This is a tough situation but I hope everyone sees this as an
>>> opportunity. Please let's discuss this openly in civilize manner.
>>> Focusing on how to solve these points rather than looking at the past.
>>> Please talk to each other. Can you/we work this out together?
>>
>> I agree -- thanks for initiating this conversation!
>
>
>

Mime
View raw message