httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: RTC killed the open source project
Date Tue, 09 Aug 2005 14:40:00 GMT
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

View raw message