httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <p...@querna.org>
Subject Re: svn commit: r1200457 - /httpd/httpd/trunk/modules/apreq/
Date Fri, 11 Nov 2011 15:43:17 GMT
On Fri, Nov 11, 2011 at 7:36 AM, Stefan Fritsch <sf@sfritsch.de> 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)

Mime
View raw message