I don't think there is any policy or standard about RTC or CTR.
different groups do different things, depending on the community.
so I don't see this as a hang up for graduation.
On Nov 6, 2009, at 10:57 AM, 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)
- R.
--
Ian Holsman
i...@holsman.net
