On Tue, Apr 7, 2009 at 1:10 PM, Torsten Curdt <tcu...@apache.org> wrote:
> Hey folks, > > I thought back and forth about whether this email should go to the > private list or not. But I have a Cocoon background and in Cocoon land > we found it useful to only use the private list when there is really > no other way. This is about the community so I think it deserves to be > discussed in the open. I hope no one is offended by that approach. > Thanks for doing it this way. > > Let me try to explain how I see the history of Cassandra. Please > correct me where I am wrong: > > Cassandra was (mainly?) developed by Facebook and is being used in > production over there. At some stage it got open sourced on Google > Code. External contributors did not feel like there is a real > community around it as patches did not get applied. Out of frustration > people started (or at least proposed) to fork the code base. As a fork > means community fragmentation the projects has turned to the Apache > Incubator hoping to turn this fragmented contributors into a healthy > community. > > In January the project got accepted. Papers were filed and in March we > saw the code enter the Apache subversion repository. A few weeks later > a first committer was proposed. Unfortunately no one noticed that the > actual authors bringing the code were NOT on the private list where > the vote was held. So we got a new committer without the consent > and/or feedback of the original authors. A big surprise. I disagree here, I was fully aware that we hadn't formed the PPMC from the committership yet (read PPMC = mentors) and at least on my side it was by design. I should probably have pointed it out at the time just in case though, my bad. Avinash and Prashant are two very nice fellows but the Cassandra community has to be larger than FB employees and actually was already, given the different forks that were developed here and there. Waiting to form the PPMC until it's more balanced in this case seems like a reasonable thing to do. > The people > that brought over the code now feel a bit betrayed by the process. > They have to deal with a committer that does changes all over the > place on a code base they depend on for production. They have the > feeling these changes are untested (at least not tested enough to get > right into production at Facebook) and that this destabilize the code > base. I wasn't aware of those feelings but I don't think they're justified, many different projects are in production in many different environments in the foundation and changes aren't a problem. That's what stable branches are for. Cassandra is now an Apache project, if it's successful it will be developed by a much larger community that it used to. That's the main goal, not a byproduct of incubation. What I would expect from committers more experienced in the codebase is guidance and transmission of expertise, not code freeze. > On the other hand there is new blood, new drive to the project. > While Facebook needs it's stability, other contributors needs the > change to meet their goals and deadlines. > > 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!) > If what you mean is that it was low because there was less direct peer review, I would agree (although I would consider Ian as a peer). If what you mean is that Jonathan hasn't enough merit to be a committer, I would disagree. Just have a look at his giithub branch :) > > 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) > > 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? > A very useful tool here is what in Apache lingo is called "lazy consensus". Anybody can build a proposition and submit it in the open. If nobody objects in a reasonable amount of time (usually 72 hours), then it's considered adopted. So I've read a couple of propositions from Jonathan on these points, why not formalizing that? > > 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) > > 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? > > Anything else I am missing? > That's a good list :) Matthieu > > 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? > > cheers > -- > Torsten >
