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:43:14 GMT
----- Original Message ----

> From: Issac Goldstand <margol@beamartyr.net>
> To: Joe Schaefer <joe_schaefer@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.


      

Mime
View raw message