----- Original Message ----
> From: Issac Goldstand <[email protected]> > To: [email protected] > 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.
