httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: RTC killed the open source project
Date Tue, 09 Aug 2005 15:34:52 GMT

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)


View raw message