httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <mar...@beamartyr.net>
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 19:40:32 GMT
Joe Schaefer wrote:
> ----- 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.
>
>   
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

Mime
View raw message