On Fri, Nov 11, 2011 at 7:36 AM, Stefan Fritsch <[email protected]> wrote: > 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.
After some reflection I agree with Stefan. +1 to branch 2.4.x from r1200449. (There will be a handful of non-apreq revs to merge, but should be a 15 minute thing)
