Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-Id: <4305EFFD.6720.00AC.0@novell.com>
Date: Fri, 19 Aug 2005 14:43:58 -0600
From: "Brad Nicholes" <BNICHOLES@novell.com>
To: <dev@httpd.apache.org>
Subject: Re: Thoughts on Future Versions/Backporting
References: <4305F385.6010604@force-elite.com>
 <cc67648e05081910487b68263b@mail.gmail.com>
In-Reply-To: <cc67648e05081910487b68263b@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

   I think the point is that we should put more effort in looking
forward rather than back.  The problem is that given the current mode of
operation, people know that the only way a patch or enhancement gets
looked at or released in any reasonable amount of time, is by
backporting it into the 2.0.x branch.  Otherwise it will most likely sit
in trunk for months if not years waiting for some future major release
of the web server.  Take the rearchitecture of the auth modules for
example.  That enhancement has been sitting in trunk for something like
2 years now.  By pushing for more point releases rather than revisions,
we not only get the needed patches out to the community, we also get
enhancements out as well.  Thus moving the web server forward rather
than back.  There are times when a critical fix needs to be backported,
but the goal should be to move trunk forward rather than patches
backwards.

my 2 cents,

Brad 

>>> On Friday, August 19, 2005 at 11:48 am, in message
<cc67648e05081910487b68263b@mail.gmail.com>, trawick@gmail.com wrote:
> On 8/19/05, Paul Querna <chip@force-elite.com> wrote:
> 
>> I think part of our problem is that we backport too much.  We
currently
>> backport security fixes, small bug fixes, big bug fixes, and even
>> complete subsystem rewrites.
>> 
>> I believe that a more scalable design, is that "we" should try to
only
>> backport small items.  This has several major effects, like making
it
>> easier to vote on items in the STATUS file, since it is generally
easier
>> to understand a single two line bug fix, rather than an entire
rewrite
>> of a module.
> 
> How about a section at the top of the STATUS file for backports that
> change < 20 lines so that folks don't have to manually weed out
STATUS
> entries beyond their threshhold?
> 
> Three people massaged/reviewed/approved some piece of code.  That's
> good enough for me, and I'm confused why it isn't (at least) good
> enough for everybody else.  Let the votes fall where they may. 
> Everything will die in due course.
> 
>> At a personal level, I intend to only help backport small items, and
I
>> will help with creating stable branches more often, to get all our
new
>> features out to users.
> 
> The current system allows your "personal level" and my "personal
> level" and everybody else's "personal level" to be merged
> appropriately, except when
> 
> * somebody wants to backport something without enough positive
reviews
> * somebody wants to prevent the backport of something that does have
> enough positive reviews