The fact of the matter is it is very hard to defend every decision by going down memory lane. That's all. I apologize if it came across as condescending but that definitely was NOT the intent. Avinash
On Tue, Apr 7, 2009 at 9:51 PM, Avinash Lakshman <avinash.laksh...@gmail.com > wrote: > 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 >> > > >> > >> > >
