You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2011/11/11 03:28:00 UTC
Re: svn commit: r1200457 - /httpd/httpd/trunk/modules/apreq/
On Thu, Nov 10, 2011 at 10:07 AM, <pg...@apache.org> wrote:
> Author: pgollucci
> Date: Thu Nov 10 18:07:07 2011
> New Revision: 1200457
>
> URL: http://svn.apache.org/viewvc?rev=1200457&view=rev
> Log:
> import apache 2.x module portion of apreq
I'm not sure what is the first comment of the apreq to httpd trunk
which I should reply to, because when I saw some of the commits I
wondered why I was receiving the commit e-mails for another tree ;)
Anyway:
* 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.
Here's what I think we need to do:
1. Prune this out of the 2.4.x branch when it is created.
2. Take our time to decide whether this should stay in trunk.
a. I guess this deliberation would involve making some compelling
changes to some of the bundled modules to use apreq instead of using
duplicate implementations, and once this is done it will probably make
sense to most.
b. Decide how it should be packaged. (If it is an integral API I'd
rather it be statically linked but opinions will surely vary.)
Etc.
We can add it to 2.4.x later if there is sufficient agreement.
Re: svn commit: r1200457 - /httpd/httpd/trunk/modules/apreq/
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Nov 10, 2011 at 6:28 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Thu, Nov 10, 2011 at 10:07 AM, <pg...@apache.org> wrote:
>> Author: pgollucci
>> Date: Thu Nov 10 18:07:07 2011
>> New Revision: 1200457
>>
>> URL: http://svn.apache.org/viewvc?rev=1200457&view=rev
>> Log:
>> import apache 2.x module portion of apreq
>
> I'm not sure what is the first comment of the apreq to httpd trunk
^^^^^^^^^
commit
Re: svn commit: r1200457 - /httpd/httpd/trunk/modules/apreq/
Posted by Jim Jagielski <ji...@jaguNET.com>.
This is done:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
Let the games begin!
Re: svn commit: r1200457 - /httpd/httpd/trunk/modules/apreq/
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Nov 11, 2011, at 7:36 AM, Stefan Fritsch wrote:
> 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
>
++1…
Will wait a bit and will then create the branch...
Re: svn commit: r1200457 - /httpd/httpd/trunk/modules/apreq/
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/11/2011 9:43 AM, Paul Querna wrote:
> On Fri, Nov 11, 2011 at 7:36 AM, Stefan Fritsch<sf...@sfritsch.de> wrote:
>>
>> 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)
If the goal is to drive towards 3.0 with the major input/output filtering
improvements you've suggested, integrate apreq, and drop some of these
dirt-simple-stupid modules into core where they belong, then by all means,
let's fork so that people aren't stepping on one another's toes with
both stability changes and new development.
Nothing says that apreq couldn't then be backported from trunk for 2.4.1.
We aren't API-stable throughout a {rev}.{even} cycle, only backwards
compatible throughout that cycle.
But if we are now at 2.0/2.2/2.4/3.0 then it is time to kill 2.0. I've
started a thread on that topic.
Re: svn commit: r1200457 - /httpd/httpd/trunk/modules/apreq/
Posted by Paul Querna <pa...@querna.org>.
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)
Re: svn commit: r1200457 - /httpd/httpd/trunk/modules/apreq/
Posted by Stefan Fritsch <sf...@sfritsch.de>.
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
Re: svn commit: r1200457 - /httpd/httpd/trunk/modules/apreq/
Posted by Joe Orton <jo...@redhat.com>.
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
Re: svn commit: r1200457 - /httpd/httpd/trunk/modules/apreq/
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Nov 10, 2011 at 6:51 PM, Philip M. Gollucci
<pg...@taximagic.com> wrote:
> On 11/10/11 6:28 PM, Jeff Trawick wrote:
>>
>> On Thu, Nov 10, 2011 at 10:07 AM,<pg...@apache.org> wrote:
>>>
>>> Author: pgollucci
>>> Date: Thu Nov 10 18:07:07 2011
>>> New Revision: 1200457
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1200457&view=rev
>>> Log:
>>> import apache 2.x module portion of apreq
>>
>> I'm not sure what is the first comment of the apreq to httpd trunk
>> which I should reply to, because when I saw some of the commits I
>> wondered why I was receiving the commit e-mails for another tree ;)
>
> We've actually been discussing it for 2yrs now, very sporadically on and off
> list. I don't think we've found anyone that doesn't want it in httpd.
> (minus the perl part obviously).
>
Since it apparently wasn't clear, I'll clarify: From here up is the
extent of my bitching. From here down I assume it stays in trunk and
am discussing only the issue of the 2.4 branch (i.e., not suggesting
that it should be yanked from trunk). Summary of 2.4 branch
suggestion: Don't ship it in 2.4.x until further discussion on
inclusion and packaging and actual use by bundled modules.
>
>> 1. Prune this out of the 2.4.x branch when it is created.
>
> Just b/c its in trunk doesn't mean you have to use it. I think a lot of
> people would like to see it there; particularly for mod_lua. They can speak
> up.
>
>> a. I guess this deliberation would involve making some compelling
>> changes to some of the bundled modules to use apreq instead of using
>> duplicate implementations, and once this is done it will probably make
>> sense to most.
>
> clearly, but it has to be in trunk, build, install, and work before you can
> start coverting.
>
>> b. Decide how it should be packaged. (If it is an integral API I'd
>> rather it be statically linked but opinions will surely vary.)
>> Etc.
>
> It includes at current a module and a library. Historically its been
> available as both a .so and .la.
Regarding the API, I am leaning towards statically linking it into
httpd/libhttpd.dll instead of delivery as a bundled .so.
>
>
>
> --
> ------------------------------------------------------------------------
> 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
> Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
> Member, Apache Software Foundation
> Committer, FreeBSD Foundation
> Consultant, P6M7G8 Inc.
> Sr. System Admin, Ridecharge Inc.
>
> Work like you don't need the money,
> love like you'll never get hurt,
> and dance like nobody's watching.
>
--
Born in Roswell... married an alien...