On Aug 9, 2005, at 7:40 AM, Nick Kew wrote:
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.
That kind of discussion happened MORE with CTR. I used to
read every commit message to see if it touched code that I cared
about, but now every commit message has the same subject ("svn
commit: <useless number> [end of title]") and I have to be
online to update my repository to read STATUS to find out what
needs reviewing. It's all just pointless bureaucracy.
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.
It seems to me that the entire project is languishing.
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".
Amusing that you should bring this up. This hybrid approach is
EXACTLY how it was before.
1) Small patches are simply committed to HEAD/trunk
2) Large changes are posted to the mailing list and given a few days
for review and discussion.
3) Everyone trusts everyone else to be reasonable about how they
define "large" and "small", and we err on the side of large.
4) Vetoes (only with a valid technical reason) cause code to be revoked
with a followup discussion about how to solve the veto.
- no more having discussion in STATUS files
- no more red tape for simple backports
- no restrictions on what people are allowed to work on (if they want to
add features to an older version of apache, don't stop them)
-aaron
