httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Whereforeartthou, 2.5.0?
Date Wed, 10 Jul 2013 18:38:55 GMT
All good points... IMO, if people consider themselves a
2.4 developer, their *primary* repo to be working on MUST
be trunk... all their work and *testing* must be on that
codebase. Yes, trunk exists for sandbox type of work,
but it also is the ONLY way that code gets backported to
2.4, so at present it's serving dual roles. Which may not
be optimal.

On Jul 10, 2013, at 2:20 PM, Stefan Fritsch <sf@sfritsch.de> wrote:

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


Mime
View raw message