Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <419BD47A.8000002@apache.org>
Date: Wed, 17 Nov 2004 22:45:14 +0000
From: Matthieu Estrade <mestrade@apache.org>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040913)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Fwd: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
References: <s19a4292.070@sinclair.provo.novell.com>
	 <20041117194208.GA1172@redhat.com>
 <cc67648e04111712203b8d7dba@mail.gmail.com>
In-Reply-To: <cc67648e04111712203b8d7dba@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

IMHO, I am not sure we need lazy backport on stable 2.0.
Lazy backport on 2.0 make it less stable, working for 2.1 is not really 
exciting because nobody or really few people use it.
The new auth layer in 2.1 is better than 2.0, inside 2.1 for a long time 
now, but not popular as it should be.

I think 2.1 is not public enough
Actually, i think people don't take time to use cvs + cvs on apr and 
apr-util, or don't take time to find snapshot to use 2.1. They also 
don't telnet apache.org to look what we are running. They go on 
httpd.apache.org, follow download link, and take 2.0.

A good solution would be to schedule some snapshot based on time (time 
is impartial and we will not fall in unfinished discussion) and some 
release based on dev and stability, and communicate more on these new 
features and enhancement

Regards,

Matthieu


Jeff Trawick wrote:

>On Wed, 17 Nov 2004 19:42:08 +0000, Joe Orton <jorton@redhat.com> wrote:
>  
>
>>On Tue, Nov 16, 2004 at 06:10:17PM -0700, Brad Nicholes 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.
>>>      
>>>
>>Looking through the STATUS file, there doesn't actually appear to be
>>much backport stagnation at all.  The majority of stale backport
>>proposals are stale because they are pending updates from the submitter
>>after review by others, or they have been vetoed by a reviewer.  Which
>>is all healthy.  So what's the evidence that there is a slowdown of
>>activity caused by the backport policy?
>>    
>>
>
>Yes, from current STATUS it looks like a few people (including myself)
>can take action on items which garnered sufficient interest, and
>everything else has some concerns to be considered.  IMHO, better to
>address those concerns with zero impact to being able to put out a new
>stable release at arbitrary point in time than to commit stuff to
>"stable" irrespective of such concerns and have it forgotten about.
>
>If there is stagnation which is caused by the backport process,
>perhaps it is self-imposed by the folks who don't have
>time/inclination to go through the current deliberations which are
>required to get the changes they're shepherding into the stable
>branch?  Is that it?
>
>Note that some "stagnation" issues are just that people (ME!!!) are in
>temporary binds with other responsibilities and can't put forth a lot
>of effort at present; handling these backports in such a deliberate
>manner allows some of us to put our limited time to good use -- keep
>up with the STATUS file and reviewing carefully identified patches. 
>Not optimal, not a major reason behind the current backport mechanism,
>but useful side-effect nonetheless.
>
>  
>