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 preferences.
- 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.
Bill
