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