That is NOT what I meant. I thought I made that very clear. I said "It is very hard to recall all experiences and that there is a reason for everything". That is all. I am very careful about what I state and I always put myself in the shoes of the reader. Avinash
On Tue, Apr 7, 2009 at 9:47 PM, Matthieu Riou <matthieu.r...@gmail.com>wrote: > On Tue, Apr 7, 2009 at 8:11 PM, Avinash Lakshman < > avinash.laksh...@gmail.com > > wrote: > > > <snipped> > > (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. > > > > Look, what you're saying here is basically "we know better and you're > stupid, so don't touch our code and don't ask questions, we can't provide > answers anyway". I'm hoping that's not the way you meant it (emails do > that) > but that's the essence of what came across. You just can't run an open > source project by saying this on its development list. > > Matthieu > > > > > > 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 > > > > > >
