Joe Schaefer wrote: > ----- Original Message ---- > > >> From: Issac Goldstand <mar...@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
