On Thu, Nov 5, 2009 at 5:44 PM, Ian Holsman <i...@holsman.net> wrote:
> 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.
>
>
Me neither, hence my question. What puzzles me is that it's mostly a
technical decision not really tied to a community health criteria, so a
priori unrelated to graduation. Or it's just a clever plan from Paul to see
what kind of discussion would arise from his objection :)
Matthieu
>
> 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
>
>
>
>
