I'd like for us to seriously consider the next steps
related to the future of httpd.
In trunk we have some stuff that can be easily, or, at
least, *somewhat* easily backported to 2.4.x, and I
personally think that we should do that. But we also
have some items which cannot be backported due to API/ABI
concerns, and some of these are pretty useful things.
And finally, we have some things in trunk that will likely
need to be majorly fixed or else scrapped.
The 1st thing we need to do is classify those things
within trunk. We then need to backport what we can,
and should, and then make progress on a 2.6.x release
(please note, I am using shorthand here... yes, I know
what we *really* do is a 2.5.x which then goes to 2.6.x
but I'm hopeful we all know what I mean).
This is what I propose:
o Later on this week I svn cp trunk over to branches/2.5.x
o That branch becomes the initial source for 2.6.x
o trunk remains CTR, whereas branches/2.5.x becomes RTC
ala 2.4.x (ie: using STATUS and specific, targeted
backport requests).
o Backports to 2.4.x only come from 2.5.x
o We then release a 2nd alpha from branches/2.5.x
o We get 2.5.x into a releasable stage, whereas we
svn mv branches/2.5.x to branches/2.6.x
A combination of trunk's STATUS and 2.4.x's STATUS will
become the STATUS for 2.5.x... see below for the why (but
basically that file will serve as the place where those
above "classifications" will be documented).
The main goal is that this creates a somewhat "stable"
2.5.x branch which can be polished but as well serve as
the source for backports. Additional development continues
on trunk w/o mussing up 2.5.x... but there is also a path
that stuff in trunk can end-up in 2.6.x. In also allows us
to remove "experiments" in the old trunk (and now 2.5.x)
which are broken or, at least, doesn't have enough support
to warrant being released (a glance thru 2.4.x's STATUS file
for backports which are stagnated, etc provide some clues
on what those could be... at the least, this will provide
incentive to address those concerns or revert those additions)
For me, the main push for this are some of the various async
improvements in trunk that, at least from what I can tell,
simply cannot be backported. It is possible that those improvements
will be the primary and almost-singular distinction between
2.4.x and 2.6.x after all is said and done, but who knows...
Thoughts? Comments?
