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: domain of avinash.lakshman@gmail.com
 designates 209.85.146.181 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=BgHU8g4vulzUlYspsFSRD8OKTduj1wbErmIT08bcafz8i2Mq2thzyB+r56UrMmGXxa
         uBoS9KQ0BVBikXHHMB5yk6BUXhjqGUosyMLuyYeE0lS8AfwATFfADPOk56mOehpAozPl
         CW68dfSODXGqkhzG2BYOEKgBcko0IiZ5FnhKc=
MIME-Version: 1.0
In-Reply-To: <681F8D43-62D2-493F-9ADC-27420D46324D@Holsman.net>
References: <6c59d89a0904071310jba6da9bs59f640fa5e3f552c@mail.gmail.com>
	 <e06563880904071930n3fe9f97ejea2a1778e8053a28@mail.gmail.com>
	 <a06de5520904072011o21df108aw28100874091fffd0@mail.gmail.com>
	 <a06de5520904072026v7ab2d383w898bb82e0a0d0998@mail.gmail.com>
	 <681F8D43-62D2-493F-9ADC-27420D46324D@Holsman.net>
Date: Tue, 7 Apr 2009 20:33:21 -0700
Message-ID: <a06de5520904072033m67e741cfu4f0cd03e491dde62@mail.gmail.com>
Subject: Re: working together
From: Avinash Lakshman <avinash.lakshman@gmail.com>
To: cassandra-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016364585b61a53ad046702cb8f

--0016364585b61a53ad046702cb8f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I think someone else opened that door here.
Avinash

On Tue, Apr 7, 2009 at 8:30 PM, Ian Holsman <ian@holsman.net> 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 <
>> 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
>
>
>
>

--0016364585b61a53ad046702cb8f--