Mailing-List: contact cassandra-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <681F8D43-62D2-493F-9ADC-27420D46324D@Holsman.net>
From: Ian Holsman <ian@holsman.net>
To: cassandra-dev@incubator.apache.org
In-Reply-To: <a06de5520904072026v7ab2d383w898bb82e0a0d0998@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: working together
Date: Wed, 8 Apr 2009 13:30:24 +1000
References: <6c59d89a0904071310jba6da9bs59f640fa5e3f552c@mail.gmail.com>
 <e06563880904071930n3fe9f97ejea2a1778e8053a28@mail.gmail.com>
 <a06de5520904072011o21df108aw28100874091fffd0@mail.gmail.com>
 <a06de5520904072026v7ab2d383w898bb82e0a0d0998@mail.gmail.com>

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 <avinash.lakshman@gmail.com
>> 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 <jbellis@gmail.com>  
>> wrote:
>>
>>> On Tue, Apr 7, 2009 at 3:10 PM, Torsten Curdt <tcurdt@apache.org>  
>>> 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. :)
>>>
>>> http://www.mail-archive.com/cassandra-dev@incubator.apache.org/msg00160.html
>>>
>>>> 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:
>>>
>>> http://www.mibbit.com/?server=irc.freenode.net&channel=%23cassandra&nick=mibbit
>>> for a web client)  We have a chance to make this more than a niche
>>> project.
>>>
>>> -Jonathan
>>>
>>
>>

--
Ian Holsman
Ian@Holsman.net