Mailing-List: contact cassandra-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: tcurdt@vafer.org
Date: Tue, 7 Apr 2009 22:10:41 +0200
Message-ID: <6c59d89a0904071310jba6da9bs59f640fa5e3f552c@mail.gmail.com>
Subject: working together
From: Torsten Curdt <tcurdt@apache.org>
To: cassandra-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

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. 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. 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!)

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?

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?

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