Jim Jagielski wrote:
I think that RTC has a place, but too often RTC is used as a club
to slow down development. Small changes that could easily
be made once the code has been committed instead result in
cycles of "Wouldn't it be best to do this?" and another
round of patch-vote commences.
That kind of discussion is a Good Thing. Well, except when it
gets bogged down and leads to stalemate. For example, my most
recent contribution (ap_hook_monitor) benefitted from Jeff's
improvements to my original suggestion.
The trouble with RTC is when things simply languish and
nothing happens.
Or when someone fixes a simple bug in trunk but can't be arsed
to backport because RTC is more hassle. I plead guilty to far
too much of that myself.
CTR is better suited towards more volunteer-oriented
processes, where someone may have a lot of time today
and tomorrow, but little next week;
I expect many committers fit that description.
in RTC, stuff will
stagnate during their offline times; with CTR they can
add their code and next week, when unavailable,
people can add upon it, improve it, etc... RTC requires
a longer time commitment and availability to see
things through to the end, tough things with the
bursty nature of volunteers.
Yep. But mostly it's finding the time to review other peoples
contributions, and making sufficient nuisance of oneself to
get ones own things reviewed.
I think there could be some mileage in a hybrid policy, with
lazy consensus on simple bugfixes and RTC on any new functionality
or substantial changes. There's a problem of definition in there,
but if lazy consensus requires (say) a month in STATUS it gives ample
time for someone to shout "that's too big - needs proper RTC".
--
Nick Kew
