incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Avinash Lakshman <>
Subject Re: working together
Date Wed, 08 Apr 2009 03:26:15 GMT
Hit Send a bit too early. Thanks Torsten for bringing this up. I really
appreciate it. No one apart from committers I think should be voting for
other people becoming committer. I am assuming here only the committers are
involved with the project from a code perspective. With regards to that,
Matt I respectfully disagree with your assessment about Jonathan becoming a
committer. I strongly believe that it has to come from the committers
themselves. In short, I mean absolutely no disrespect to Jonathan or anyone
else, but Matt's assessment needs to come from the guys involved with this
on a day-day basis from a code perspective. My aim was to put forth our
frustration and not meant to put down anyone.

On Tue, Apr 7, 2009 at 8:11 PM, Avinash Lakshman <
> wrote:

> Point #1 I would love to have committers from outside but the way this
> happened took all of us by surprise. Granted we were not on the list but if
> I were one of the committers I would have definitely pinged one of the other
> committters and asked them as to whether they knew what the hell was going
> on. Anyway this is water under bridge now. I hate bitter confrontation since
> it doesn't take anyone forward but only leaves a bitter taste in everyone's
> mouth. I have had many personal conversations with Jonathan via chat and I
> have nothing personal against anyone, perhaps not everyone but definitely
> nothing against Jonathan.
> The part that is very disconcerting are the following:
> (1) If one becomes a committer one is not expected to blitz through the
> code base and start refactoring everything. There is a way this needs to be
> handled. In any organization one doesn't just go about ripping out everyone
> else's code for no rhyme or reason. That will offend anybody. I personally
> would not go about ripping someone else's code apart if I had become
> committer. It is just that respect ought to be there. There is a way to get
> this done. Changes to code because person X likes something to be in some
> particular form and going and just changing that in person Y's code is just
> plain wrong. It borders on arrogance which is not the way things should be
> done. If I become a committer on Hadoop can I just go and start ripping
> apart every class and start making changes just because I don't like the
> coding style. This is a premature project on Apache and I think we need to
> keep the original developers in the loop till everyone has some degree of
> confidence on the changes made by new committers.
> (2) This is something that I have said many times over. Certain things are
> the way they are for a reason. For example when I say ConcurrentHashMap is a
> memory hog I say it because we have seen this in practice. How does it
> manifest itself? I obviously do not recall since all this was over a year
> ago. No one can claim to have run tests the way we have in the last year and
> a half. One cannot just run some simple test and say well I do not see the
> problem. I am not dumb. Anyone having gone through the exercise of having
> built a system like this in an organization will realize that the tests are
> very intermingled with the organization's infrastructure. I have no time to
> rip that all apart and put together a test suite at this point. This is just
> an example. There are many such instances - after all - we are the ones who
> have the operational experience with this and I do not think anyone can
> claim to understand the behavior this system in production workloads better
> than we do.
> My understanding was that new committers come in and start with some
> feature implement that and then slowly start looking into what more they
> could do going forward. It is NOT come in and refactor the hell out of the
> system because you like something to be in a specific way. I do not beleive
> this will fly in any community. It is something like we now going through
> the entire code base and changing all the stuff just because I like it in a
> specific way. This seems ludicrous. We may have no experience in open source
> but we understand etiquette very well. This just doesn't seem the way things
> work in other Apache projects which are successful. We work very closely
> with two committers from the Hadoop project who were flabbergasted with the
> refactor changes that were going in. That is my gripe with the whole thing.
> Cheers
> Avinash
> On Tue, Apr 7, 2009 at 7:30 PM, Jonathan Ellis <> wrote:
>> On Tue, Apr 7, 2009 at 3:10 PM, Torsten Curdt <> wrote:
>> > 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!)
>> It's unfortunate that Avinash and Prashant weren't part of the
>> process.  Still, when I talked to Avinash on March 1, he told me [and
>> this is a direct quote] "If I had known you earlier I would have added
>> you as a committer."  So when I asked one of the mentors how to become
>> a committer and it worked out from there it did not occur to me that
>> anything was wrong.
>> >
>> > 2. A missing definition of development process:
>> >  - What is considered a valid code review?
>> >  - How much are changes discussed up-front?
>> I think we have a handle on this now.  All changes are put on Jira for
>> review and are not committed until there is at least one +1 from a
>> reviewer.  (I personally prefer post-commit review because manually
>> attaching and applying patches is tedious but we don't have enough
>> people following the commit log for that to work right now.)
>> >  - What is the roadmap? ...for whom? (weighted as a community)
>> That's worth a separate thread. Such as this one. :)
>> > 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'm happy to assist with merging code to or from stable branches in
>> this scenario.
>> > 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?
>> This can still be a win/win for everyone.  I think that historically
>> facebook has felt like the community hasn't contributed much of value,
>> but we're starting to change that. The build and test process is
>> dramatically better than it was before thanks to community
>> contributions.  We have a real daemon mode.  (Well, not in the purest
>> sense, but it runs in the background nicely w/o nohup or screen. :)
>> We've also found and fixed several concurrency bugs, and we're well on
>> the way to having remove and range queries implemented.
>> Our IRC population has more than doubled.  (#cassandra on freenode:
>> for a web client)  We have a chance to make this more than a niche
>> project.
>> -Jonathan

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message