Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: Re: Whereforeartthou, 2.5.0?
Date: Wed, 10 Jul 2013 20:20:22 +0200
User-Agent: KMail/1.13.7 (Linux/3.9-1-amd64; KDE/4.8.4; x86_64; ; )
References: <20130710011910.202158ca@hub>
 <AE5B4015-50A0-4CEB-959F-A90EC58F23EF@jaguNET.com>
 <20130710105430.21135b6f@hub>
In-Reply-To: <20130710105430.21135b6f@hub>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201307102020.22681.sf@sfritsch.de>

On Wednesday 10 July 2013, William A. Rowe Jr. wrote:
> Jim Jagielski <jim@jaguNET.com> wrote:
> > In any case, I *am* concerned that w seem to have quite a bit of
> > difficulty in getting 3 +1s a lot of the time and that the
> > backport process from trunk to 2.4 is becoming more and more
> > painful. [...]

Jim, I think you are particularily affected by that problem because 
you hack a lot on mod_proxy, which is a complex beast. Of the few 
active committers, not all are comfortable reviewing changes there. 
The same is probably true for Graham and mod_cache.

> What I am asking, is whether that trunk is a sandbox to hack in, or
> whether is is approaching a releasable state?  I'm asking, whether
> trunk is a worthwhile exercise or a distraction and complication to
> fixing and enhancing the shared, released project code,
> branches/2.4.x?

trunk is needed for changes that break API/ABI compatibility. And I 
think it is also very useful for complex changes that take time to get 
into a releasable state. If you take that away, the result will be 
that branches/2.4.x-renamed-to-trunk will not be always in a 
releasable state, because it will contain unfinished/broken changes. 
This may deter people from volunteering as RM because they would first 
have to clean up the mess by fixing open issues or reverting changes. 
And the quality of 2.4 releases will probably suffer, too.

The same is true if we make 2.4 completely CTR or the 72 hour scheme 
proposed by Jim. But I would be open to CTR 2.4 for some classes of 
changes, maybe simple bug fixes with no (public or private) API 
change, or for changes that have reasonable test coverage in the test 
framework.

WRT 2.5/2.6, I very much hope that it will not take as long as the 
2.2->2.4 cycle. I am pretty sure that we cannot reasonably support 
SPDY/HTTPbis/HTTP2.0 in 2.4, so we will need a 2.6 in the forseeable 
future.