httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
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
Date Sat, 10 Jan 2009 16:03:14 GMT


----- Original Message ----

> From: Issac Goldstand <margol@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.


      

Mime
View raw message