Re: working together

[Ian Holsman]

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.laksh...@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 <jbel...@gmail.com>  
wrote:

On Tue, Apr 7, 2009 at 3:10 PM, Torsten Curdt <tcu...@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
i...@holsman.net