+1 for Sandeeps development process suggestions. In order to address some of the issues brought forward in this thread I have adapted the following wiki pages from other projects and from various emails. They could serve as the basis for an initial process.
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!
