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 >> > >
