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:33:21 GMT
I think someone else opened that door here.

On Tue, Apr 7, 2009 at 8:30 PM, Ian Holsman <> wrote:

> guys.
> we have a private list to discuss the pro's and con's of people being a
> comitter.
> keep these personal discussions off the development list. It doesn't help
> anyone.
> as was mentioned several times. we assumed you subscribed when you were
> asked to on the 20th of January.
> On 08/04/2009, at 1:26 PM, Avinash Lakshman wrote:
>  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.
>> Cheers
>> Avinash
>> 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
> --
> Ian Holsman

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