httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
Date Wed, 17 Nov 2004 01:24:25 GMT
moving to dev@ list

>>> BNICHOLES@novell.com Tuesday, November 16, 2004 6:04:08 PM >>>
   This proposal is in addition to the proposal on the dev list.  Once the code converts from
CTR to RTC in a stable branch, then we need a way to make sure that overhead doesn't stifle
ennovation.  The fact is that users and casual developers pay more attention to the stable
branch rather than HEAD.  Why?? Because that is what matters to them.  If there is an itch
that needs to be scratched, it's in the code that they are depending on to run their site.
 That is usually not the bleeding edge.

Brad

>>> 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.  

I think, the RTC policy for 2.0 is a good thing. It *forces* reviews, which
actually often helped to prevent introducing new bugs (not always though, but
that's probably another issue).

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.

nd
-- 
Das einzige, das einen Geb├Ąudekollaps (oder auch einen
thermonuklearen Krieg) unbeschadet ├╝bersteht, sind Kakerlaken
und AOL-CDs.
                                      -- Bastian Lipp in dcsm



Mime
View raw message