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 00:12:29 GMT
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