incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill de hOra <>
Subject Re: Graduation?
Date Fri, 06 Nov 2009 02:05:41 GMT
Roland Dreier wrote:
>  > I do think there should be room for individual discretion here.  If
>  > you have a trivial change, just commit it and be done.  But in
>  > general, I think the extra care of RTC is usually worth it for us.  I
>  > see reviews becoming a lot more perfunctory / not happening at all if
>  > we just commit first.  (Just about all my experience has been in CTR
>  > projects, both closed and OSS.  This isn't just a theoretical concern,
>  > DESPITE the best of intentions that "we'll do reviews, promise.")
> This gets to my central question, which I would be really happy to
> have answered by a CTR proponent.  How do you make sure that changes
> *ever* get reviewed, since CTR seems to operate on lazy consensus ("if
> you object to this change, speak up")?  *everyone* would rather write
> code rather than review someone else's changes, so it seems that the
> quantity of changes going in is always going to exceed the amount of
> review being done, leading to an ever-growing review backlog.
> I just don't see how CTR can scale to a big project.  It might scale
> to a big codebase, if each piece has only one or a few committers
> touching it, but when a lot of people are all working on the same
> stuff, I wonder how anything will get reviewed in time.
> (FWIW, my background is pretty much exclusively in RTC projects such
> as the Linux kernel)

Looking at this codebase as a non-committer/fanboy, I think it needs RTC 
for a while, in a way that has nothing to do with the vcs or policy 

  - there are parts that are just not widely understood. If 10 people 
outside FB understand how the failure detector works or what happens 
after a crash, or cross-dc bootstrap, I'd be delighted.  And it seems to 
me that small code changes can impact global behavior. Cassandra really 
pushes the state of the art.

- the code is hard to write tests over and is a monolith by my 
standards. Basically, it's full of statics and that it isn't going to 
get better anytime time soon if the style rules encourage things like 
linebreaks as means to organize methods and the patch process is 
optimized for the reviewer rather than code's structural health. [I'm 
assuming that Cassandra will either modularise at some point the way 
hadoop did, or simply collapse due to complexity.]

- the disk format, apis, and clients aren't stable. IMO any changes 
around mem/sstables or the commitlog warrants review.

- there's no trust hierarchy a la the kernel (or hadoop) that weeds out 
bozos, and people here haven't gravitated to a subsystem maintenance 
model yet.

- CTR isn't obviously slowing things down at the moment (that could 
change if Cassandra becomes a big project). It seems pretty active to me 
compared to other "unsql" projects.

So given the above I would wait for a while and if that stops graduation 
so be it.

My concerns with RTC are that it might stop people getting involved 
and/or the checkin process bottlenecks on the committers. If either 
happens that should be obvious.


View raw message