> 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)
- R.
