On Thu, 10 Nov 2011, Joe Orton wrote:
On Thu, Nov 10, 2011 at 06:28:00PM -0800, Jeff Trawick wrote:
* There should have been a discussion on dev@ before promoting a
subproject to the main distribution.
* Two weeks before 2.4 GA (well, that's the general desire of those of
the group that spoke up) and after the last planned beta was cut is
not a great time to do this anyway.
I agree with Jeff, this is going to require a lot more effort to get
into a shippable state (across all platforms etc). Joe
I also think that the timing could not have been worse. Dumping 5000 lines
of C-code and 2000 lines of headers into httpd now would delay the release
for at least 1-2 months:
- people need some time to review that code
- the build is broken at least on non-unix
- apreq would need to be adjusted to recent developments in httpd
- duplicate code in httpd would need to be removed / changed to use apreq.
This is especially true for the new mod_request which seems to offer a
subset of apreq's functionality.
I see three possible ways forward. In order of personal preference:
1) branch 2.4.x from trunk r1200449, which was the last revision before
apreq
2) somehow disable apreq in the default build (e.g. require a
--enable-broken-experimental-features configure switch) and document that
its API/ABI is unstable and otherwise ignore it for the release
3) Wait with the release until the issues are sorted out.
I really don't want to delay the release further. At some point one has to
draw the line and not include major new features. Also, a 2 month delay
would mean that it would be impossible to include 2.4.x in the next stable
Debian release (7/wheezy). The freeze date is scheduled for June 2012 and
there is much work required to stabilize 2.4.x and update all the module
packages. This would mean that it would take until the second half of
2014(!) until 2.4.x would be available in a Debian stable release.
Also, due to the way Ubuntu pulls packages from Debian unstable, it would
take at least until 4/2013 until 2.4.x could be included in a Ubuntu
release (though 10/2013 seems more likely).
I think solution 1) is preferable. There is no reason why apreq can't be
included in 2.4.2 or 2.4.3, once its inclusion has been completed.
Therefore I don't see any advantage in 2) and having a 2.4.x branch now
would prevent further accidents like this one.
In any case, if including apreq in some version of 2.4.x is planned, we
should not release mod_request with 2.4.0.
Cheers,
Stefan
