You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Issac Goldstand <ma...@beamartyr.net> on 2009/01/10 16:51:57 UTC
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h
library/module_cgi.c library/parser.c module/apache2/handle.c
Shouldn't we *not* be doing this type of backport? We really don't need
release branches any more if we're going to be voting directly on
release artifacts, since there are no changes that can be made to them
anyway. I'm -0.9 for 2.10 if this looks like a showstopper for building
with gcc4 and let's start a 2.11 release. Otherwise, we're gonna run
into the same issues we just had with the 1.34-RC4 vote.
Issac
joes@apache.org wrote:
> Author: joes
> Date: Fri Jan 9 17:42:05 2009
> New Revision: 733221
>
> URL: http://svn.apache.org/viewvc?rev=733221&view=rev
> Log:
> backport r733216 to v2_10 branch
>
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Bojan Smojver <bo...@rexursive.com>
> To: Issac Goldstand <ma...@beamartyr.net>
> Cc: Joe Schaefer <jo...@yahoo.com>; APREQ List <ap...@httpd.apache.org>
> Sent: Monday, January 12, 2009 12:31:57 PM
> Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
>
> On Mon, 2009-01-12 at 18:44 +0200, Issac Goldstand wrote:
>
> > Regardless of that, I'd like to merge in the enhanced-cgi stuff later in
> > the week. So we can either do 2 consecutive releases or get 2.10 out
> > the door now and re-vote on 2.11 in another week or so.
>
> We didn't have a release for a very long time, so one extra week isn't
> going to make a lot of difference. People have been asking for enhanced
> CGI stuff, so let's do that. Everyone OK with that approach?
Fine with me. I'm no longer committing stuff to the v2_10 branch, so someone
should probably nuke it.
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10:
include/apreq_version.h library/module_cgi.c library/parser.c
module/apache2/handle.c
Posted by Bojan Smojver <bo...@rexursive.com>.
On Mon, 2009-01-12 at 18:44 +0200, Issac Goldstand wrote:
> Regardless of that, I'd like to merge in the enhanced-cgi stuff later in
> the week. So we can either do 2 consecutive releases or get 2.10 out
> the door now and re-vote on 2.11 in another week or so.
We didn't have a release for a very long time, so one extra week isn't
going to make a lot of difference. People have been asking for enhanced
CGI stuff, so let's do that. Everyone OK with that approach?
--
Bojan
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h
library/module_cgi.c library/parser.c module/apache2/handle.c
Posted by Issac Goldstand <ma...@beamartyr.net>.
Joe Schaefer wrote:
> ----- Original Message ----
>
>
>> From: Bojan Smojver <bo...@rexursive.com>
>> To: Joe Schaefer <jo...@yahoo.com>
>> Cc: Issac Goldstand <ma...@beamartyr.net>; apreq-dev@httpd.apache.org
>> Sent: Monday, January 12, 2009 11:09:23 AM
>> Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
>>
>> On Mon, 2009-01-12 at 06:32 -0800, Joe Schaefer wrote:
>>
>>> Are you planning to pursue 2.10 as RM or
>>> should we be moving on to 2.11? The only outstanding issue I am aware
>>> of is pgollucci's claim that the perl modules aren't linking correctly
>>> to libapreq2 on Solaris. While that would be nice to fix, I don't consider
>>> it a showstopper either.
>>>
>> I'm kinda waiting for the outcome of that discussion on the list before
>> we go ahead. From what I can see, current decision is to have 2.11
>> released, right? If so, let's roll that (I'm not attached to version
>> numbers in any way).
>>
>
> I've looked over pgollucci's build tree on the perl zone and confirmed
> that the perl .so modules cannot locate either libapreq2 nor libapr.
> We may need to add more rpath-related stuff to our linking flags.
>
> With respect to 2.10 or 2.11, it all depends on what we wanna do with that
> v2_10 branch. It's current now, and I don't mind keeping it synced with
> trunk if someone's planning to release from it this week. But if not, I
> think we should move on to 2.11.
>
>
>
>
Regardless of that, I'd like to merge in the enhanced-cgi stuff later in
the week. So we can either do 2 consecutive releases or get 2.10 out
the door now and re-vote on 2.11 in another week or so.
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Bojan Smojver <bo...@rexursive.com>
> To: Joe Schaefer <jo...@yahoo.com>
> Cc: Issac Goldstand <ma...@beamartyr.net>; apreq-dev@httpd.apache.org
> Sent: Monday, January 12, 2009 11:09:23 AM
> Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
>
> On Mon, 2009-01-12 at 06:32 -0800, Joe Schaefer wrote:
> > Are you planning to pursue 2.10 as RM or
> > should we be moving on to 2.11? The only outstanding issue I am aware
> > of is pgollucci's claim that the perl modules aren't linking correctly
> > to libapreq2 on Solaris. While that would be nice to fix, I don't consider
> > it a showstopper either.
>
> I'm kinda waiting for the outcome of that discussion on the list before
> we go ahead. From what I can see, current decision is to have 2.11
> released, right? If so, let's roll that (I'm not attached to version
> numbers in any way).
I've looked over pgollucci's build tree on the perl zone and confirmed
that the perl .so modules cannot locate either libapreq2 nor libapr.
We may need to add more rpath-related stuff to our linking flags.
With respect to 2.10 or 2.11, it all depends on what we wanna do with that
v2_10 branch. It's current now, and I don't mind keeping it synced with
trunk if someone's planning to release from it this week. But if not, I
think we should move on to 2.11.
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10:
include/apreq_version.h library/module_cgi.c library/parser.c
module/apache2/handle.c
Posted by Bojan Smojver <bo...@rexursive.com>.
On Mon, 2009-01-12 at 06:32 -0800, Joe Schaefer wrote:
> Are you planning to pursue 2.10 as RM or
> should we be moving on to 2.11? The only outstanding issue I am aware
> of is pgollucci's claim that the perl modules aren't linking correctly
> to libapreq2 on Solaris. While that would be nice to fix, I don't consider
> it a showstopper either.
I'm kinda waiting for the outcome of that discussion on the list before
we go ahead. From what I can see, current decision is to have 2.11
released, right? If so, let's roll that (I'm not attached to version
numbers in any way).
--
Bojan
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Bojan Smojver <bo...@rexursive.com>
> To: Joe Schaefer <jo...@yahoo.com>
> Cc: Issac Goldstand <ma...@beamartyr.net>; apreq-dev@httpd.apache.org
> Sent: Sunday, January 11, 2009 5:10:44 AM
> Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
>
> On Sat, 2009-01-10 at 08:03 -0800, Joe Schaefer wrote:
>
> > Actually it turns out that the problem I was having at first was related
> > to Bojan's prior -fno-strict-aliasing removal. If you try building trunk
> > with maintainer-mode set, the build will fail badly without the flag.
>
> OUCH! Sorry about that - didn't attempt to compile in that mode at
> all :-(
No worries, was easy to fix. Are you planning to pursue 2.10 as RM or
should we be moving on to 2.11? The only outstanding issue I am aware
of is pgollucci's claim that the perl modules aren't linking correctly
to libapreq2 on Solaris. While that would be nice to fix, I don't consider
it a showstopper either.
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10:
include/apreq_version.h library/module_cgi.c library/parser.c
module/apache2/handle.c
Posted by Bojan Smojver <bo...@rexursive.com>.
On Sat, 2009-01-10 at 08:03 -0800, Joe Schaefer wrote:
> Actually it turns out that the problem I was having at first was related
> to Bojan's prior -fno-strict-aliasing removal. If you try building trunk
> with maintainer-mode set, the build will fail badly without the flag.
OUCH! Sorry about that - didn't attempt to compile in that mode at
all :-(
--
Bojan
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Issac Goldstand <ma...@beamartyr.net>
> To: Joe Schaefer <jo...@yahoo.com>
[...]
> >
> > I think what we need now is someone to volunteer for RM'ing a new release
> > candidate of the 2.10 branch.
> >
> -0.9 again - numbers are admittedly cheap but I just don't like the idea
> of seeing minor bumps and significant changes between RCs, but I'll
> happily voulenteer to do 2.11
>
> I'd also still like to see the interactive-mode patch for the CGI module
> merged in, merging changes back is a pain in the ass, and there are
> several folks out there using it already...
Ok, let's move on to 2.11 then. I've been reluctant to make behavioral
changes to the cgi module in the past, but I've since softened my
views, so +1 to bring that code into trunk.
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h
library/module_cgi.c library/parser.c module/apache2/handle.c
Posted by Issac Goldstand <ma...@beamartyr.net>.
Joe Schaefer wrote:
> ----- Original Message ----
>
>
>> From: Issac Goldstand <ma...@beamartyr.net>
>> To: Joe Schaefer <jo...@yahoo.com>
>> Cc: apreq-dev@httpd.apache.org
>> Sent: Saturday, January 10, 2009 11:11:28 AM
>> Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
>>
>> Joe Schaefer wrote:
>>
>>> ----- Original Message ----
>>>
>>>
>>>
>>>> From: Issac Goldstand
>>>> To: apreq-dev@httpd.apache.org
>>>> Sent: Saturday, January 10, 2009 10:51:57 AM
>>>> Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10:
>>>>
>> include/apreq_version.h library/module_cgi.c library/parser.c
>> module/apache2/handle.c
>>
>>>> Shouldn't we *not* be doing this type of backport? We really don't need
>>>> release branches any more if we're going to be voting directly on
>>>> release artifacts, since there are no changes that can be made to them
>>>> anyway.
>>>>
>>>>
>>> I think that's up to the RM. Roy's point is that we should be
>>> voting on a final (signed) tarball, not something that's going
>>> to be modified and rolled again post-vote. On EVERY release we do
>>> it takes several rounds of voting for us to come to consensus that
>>> we're actually going to approve a tarball. If the RM wants to
>>> handle that process by labelling the tarballs with an RC marker,
>>> or wants to bump the package version number each time (which is
>>> something of a pain here), it makes no difference to me.
>>>
>>>
>> Fair enough.
>>
>
> OTOH it is something of a PITA to keep patching trunk and the release
> branch, which means we should either release 2.10 soon or abandon that
> version and make a fresh 2.11 branch of trunk.
>
>
Which is kinda what I was hinting at in the first place... +1
>
>>> The release docs for apreq-1 are totally wrong and should be brought
>>> up to speed with the release docs for apreq2.
>>>
>>>
>>>
>> +1 - I'll get to that this week, I hope (and improve the 2.0 docs a bit
>> too, based on recent issues discovered during the 1.34 release). Will
>> also try to make some easier version bumping tools (though that actually
>> was really simple and pretty accurate in RELEASE, unless I missed something)
>>
>>>> I'm -0.9 for 2.10 if this looks like a showstopper for building
>>>> with gcc4 and let's start a 2.11 release. Otherwise, we're gonna run
>>>> into the same issues we just had with the 1.34-RC4 vote.
>>>>
>
> Thanks! What I'd really like to see us get in the habit of doing is discussing
> the gpg signatures as well. IMO the RM should post the sig alongside
> the tarball so other devs can test that too, and we devs should offer our
> +1's with our *own* signature of the tarball attached to the vote message.
>
>
I've been trying to do that anyway. Remind me to add an @apache.org
subkey and get it signed at the next ApacheCon keysigning party to make
my sigs nicer :) Hopefully I'll make it this March.
> We then can collect *all* the sigs and put them into the final .asc file for
> the released tarball.
>
>
If we really want to adopt gpg sigs, we should really also adopt
Module::Signature for the perl glue, at least.
>>> Actually it turns out that the problem I was having at first was related
>>> to Bojan's prior -fno-strict-aliasing removal. If you try building trunk
>>> with maintainer-mode set, the build will fail badly without the flag.
>>>
>>>
>> As I said earlier, I'm still for a new RC at the least.
>>
>
> I think what we need now is someone to volunteer for RM'ing a new release
> candidate of the 2.10 branch.
>
-0.9 again - numbers are admittedly cheap but I just don't like the idea
of seeing minor bumps and significant changes between RCs, but I'll
happily voulenteer to do 2.11
I'd also still like to see the interactive-mode patch for the CGI module
merged in, merging changes back is a pain in the ass, and there are
several folks out there using it already...
Issac
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Issac Goldstand <ma...@beamartyr.net>
> To: Joe Schaefer <jo...@yahoo.com>
> Cc: apreq-dev@httpd.apache.org
> Sent: Saturday, January 10, 2009 11:11:28 AM
> Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
>
> Joe Schaefer wrote:
> > ----- Original Message ----
> >
> >
> >> From: Issac Goldstand
> >> To: apreq-dev@httpd.apache.org
> >> Sent: Saturday, January 10, 2009 10:51:57 AM
> >> Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10:
> include/apreq_version.h library/module_cgi.c library/parser.c
> module/apache2/handle.c
> >>
> >> Shouldn't we *not* be doing this type of backport? We really don't need
> >> release branches any more if we're going to be voting directly on
> >> release artifacts, since there are no changes that can be made to them
> >> anyway.
> >>
> >
> > I think that's up to the RM. Roy's point is that we should be
> > voting on a final (signed) tarball, not something that's going
> > to be modified and rolled again post-vote. On EVERY release we do
> > it takes several rounds of voting for us to come to consensus that
> > we're actually going to approve a tarball. If the RM wants to
> > handle that process by labelling the tarballs with an RC marker,
> > or wants to bump the package version number each time (which is
> > something of a pain here), it makes no difference to me.
> >
> Fair enough.
OTOH it is something of a PITA to keep patching trunk and the release
branch, which means we should either release 2.10 soon or abandon that
version and make a fresh 2.11 branch of trunk.
> > The release docs for apreq-1 are totally wrong and should be brought
> > up to speed with the release docs for apreq2.
> >
> >
> +1 - I'll get to that this week, I hope (and improve the 2.0 docs a bit
> too, based on recent issues discovered during the 1.34 release). Will
> also try to make some easier version bumping tools (though that actually
> was really simple and pretty accurate in RELEASE, unless I missed something)
> >> I'm -0.9 for 2.10 if this looks like a showstopper for building
> >> with gcc4 and let's start a 2.11 release. Otherwise, we're gonna run
> >> into the same issues we just had with the 1.34-RC4 vote.
Thanks! What I'd really like to see us get in the habit of doing is discussing
the gpg signatures as well. IMO the RM should post the sig alongside
the tarball so other devs can test that too, and we devs should offer our
+1's with our *own* signature of the tarball attached to the vote message.
We then can collect *all* the sigs and put them into the final .asc file for
the released tarball.
> >
> > Actually it turns out that the problem I was having at first was related
> > to Bojan's prior -fno-strict-aliasing removal. If you try building trunk
> > with maintainer-mode set, the build will fail badly without the flag.
> >
> As I said earlier, I'm still for a new RC at the least.
I think what we need now is someone to volunteer for RM'ing a new release
candidate of the 2.10 branch.
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h
library/module_cgi.c library/parser.c module/apache2/handle.c
Posted by Issac Goldstand <ma...@beamartyr.net>.
Joe Schaefer wrote:
> ----- Original Message ----
>
>
>> From: Issac Goldstand <ma...@beamartyr.net>
>> To: apreq-dev@httpd.apache.org
>> Sent: Saturday, January 10, 2009 10:51:57 AM
>> Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
>>
>> Shouldn't we *not* be doing this type of backport? We really don't need
>> release branches any more if we're going to be voting directly on
>> release artifacts, since there are no changes that can be made to them
>> anyway.
>>
>
> I think that's up to the RM. Roy's point is that we should be
> voting on a final (signed) tarball, not something that's going
> to be modified and rolled again post-vote. On EVERY release we do
> it takes several rounds of voting for us to come to consensus that
> we're actually going to approve a tarball. If the RM wants to
> handle that process by labelling the tarballs with an RC marker,
> or wants to bump the package version number each time (which is
> something of a pain here), it makes no difference to me.
>
Fair enough.
> The release docs for apreq-1 are totally wrong and should be brought
> up to speed with the release docs for apreq2.
>
>
+1 - I'll get to that this week, I hope (and improve the 2.0 docs a bit
too, based on recent issues discovered during the 1.34 release). Will
also try to make some easier version bumping tools (though that actually
was really simple and pretty accurate in RELEASE, unless I missed something)
>> I'm -0.9 for 2.10 if this looks like a showstopper for building
>> with gcc4 and let's start a 2.11 release. Otherwise, we're gonna run
>> into the same issues we just had with the 1.34-RC4 vote.
>>
>
> Actually it turns out that the problem I was having at first was related
> to Bojan's prior -fno-strict-aliasing removal. If you try building trunk
> with maintainer-mode set, the build will fail badly without the flag.
>
As I said earlier, I'm still for a new RC at the least.
Issac
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Issac Goldstand <ma...@beamartyr.net>
> To: apreq-dev@httpd.apache.org
> Sent: Saturday, January 10, 2009 10:51:57 AM
> Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
>
> Shouldn't we *not* be doing this type of backport? We really don't need
> release branches any more if we're going to be voting directly on
> release artifacts, since there are no changes that can be made to them
> anyway.
I think that's up to the RM. Roy's point is that we should be
voting on a final (signed) tarball, not something that's going
to be modified and rolled again post-vote. On EVERY release we do
it takes several rounds of voting for us to come to consensus that
we're actually going to approve a tarball. If the RM wants to
handle that process by labelling the tarballs with an RC marker,
or wants to bump the package version number each time (which is
something of a pain here), it makes no difference to me.
The release docs for apreq-1 are totally wrong and should be brought
up to speed with the release docs for apreq2.
> I'm -0.9 for 2.10 if this looks like a showstopper for building
> with gcc4 and let's start a 2.11 release. Otherwise, we're gonna run
> into the same issues we just had with the 1.34-RC4 vote.
Actually it turns out that the problem I was having at first was related
to Bojan's prior -fno-strict-aliasing removal. If you try building trunk
with maintainer-mode set, the build will fail badly without the flag.