httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Astrid Ke├čler <k...@kess-net.de>
Subject Re: Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
Date Thu, 18 Nov 2004 23:41:02 GMT
>>>> nd@perlig.de Tuesday, November 16, 2004 4:29:31 PM >>>
> * "Brad Nicholes" <BNICHOLES@novell.com> wrote:

>>    During ApacheCon several httpd PMC members got together to discuss
>> current issues with the httpd project and to try to find better ways to
>> manage the project.  One of the issues that was discussed heavily was
>> the current policy of RTC vs CTR.  The feeling of some of the PMC
>> members is that the RTC policy as it is currently implemented on the 2.0
>> branch, is causing unnecessary overhead which has resulted in the
>> slowdown of activity in the httpd project.  One proposal that was made
>> would be to adopt a lazy consensus rule.  Basically what this means is
>> that when a backport is proposed in the STATUS file, after a period of
>> time and if the proposal has not recieved any 0 or -1 votes, it would
>> automatically be approved for backport by lazy consensus.  The purpose
>> for this proposal is to avoid stagnation of backport proposals in the
>> STATUS file simply due to the lack of votes.  

-1 (vote not veto)
Stability is much more important than backport of some features.
Backporting code into the stable branch without any review will
increase the risk of new bugs.

What I see, is not stagnation. Instead, I do see more effort because of
our backport policy. Development is done for two versions. This binds
time and power.

> IMHO a better way bring the development further is the suggestion on the dev
> list. *absolute* feature freeze on stable branches (except 1.3?), bug fixes
> only. Though it would need some time to establish the trust of the community
> in so much more versions, I like that idea somehow.

+1

Additionally, let's do 2.1 tarballs to bring the current development
branch to a wider group of devs and testers.

Kess


Mime
View raw message