Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
*ping* I don't actually see a vote from Steeve - just an advisory that it seems OK. I did vote +1, and am ready to roll (after having a baby boy + getting the flu twice; it's been a busy month ;)) as soon as I see a 3rd binding vote. Since steevehay does seem positive, I'm going to start tagging and rolling, but won't upload or announce until I formally close the vote Issac Philip M. Gollucci wrote: Philip M. Gollucci wrote: Issac Goldstand wrote: http://people.apache.org/~issac/libapreq-1.34-RC4.tar.gz Unit tests blow up spectacularly on solaris 2.10 but I don't think we support that and is related to Request.so failing to load. It does compile. I'll get a freebsd test for some sanity in the nearish future here. I wouldn't worry about the solaris blow ups (1.33 doesn't work either) Nothing liked getting pissed off to get things to work. (I believe the only difference I did was -httpd vs -apxs) All tests successful. Files=4, Tests=25, 3 wallclock secs ( 1.22 cusr + 0.17 csys = 1.39 CPU) Solaris 2.10 apache 1.3.41 mod_perl 1.30 perl 5.8.8 so thats a +1 Neither of Steve's changes are to apreq itself so they don't block the release. +1: stevenhay, pgollucci +0: -0: -1: ISSAC did you vote ? if you do we get the required votes. If do the release, make sure you send the e-mails from an @apache.org e-mail.
RE: [RELEASE CANDIDATE] libapreq 1.34-RC4
I didn't vote because AFAIK I don't actually have a vote. I have commit access, but I'm not a PMC member and therefore have no vote. Is that correct? -Original Message- From: Issac Goldstand [mailto:mar...@beamartyr.net] Sent: 07 January 2009 13:24 Cc: APREQ List Subject: Re: [RELEASE CANDIDATE] libapreq 1.34-RC4 *ping* I don't actually see a vote from Steeve - just an advisory that it seems OK. I did vote +1, and am ready to roll (after having a baby boy + getting the flu twice; it's been a busy month ;)) as soon as I see a 3rd binding vote. Since steevehay does seem positive, I'm going to start tagging and rolling, but won't upload or announce until I formally close the vote Issac Philip M. Gollucci wrote: > Philip M. Gollucci wrote: >> Issac Goldstand wrote: >>> http://people.apache.org/~issac/libapreq-1.34-RC4.tar.gz >> Unit tests blow up spectacularly on solaris 2.10 but I don't think we >> support that and is related to Request.so failing to load. >> >> It does compile. >> >> I'll get a freebsd test for some sanity in the nearish future here. >> >> I wouldn't worry about the solaris blow ups (1.33 doesn't work either) >> >> > Nothing liked getting pissed off to get things to work. > (I believe the only difference I did was -httpd vs -apxs) > > All tests successful. > Files=4, Tests=25, 3 wallclock secs ( 1.22 cusr + 0.17 csys = 1.39 > CPU) > > Solaris 2.10 > apache 1.3.41 > mod_perl 1.30 > perl 5.8.8 > > so thats a +1 > > Neither of Steve's changes are to apreq itself so they don't block the > release. > > +1: stevenhay, pgollucci > +0: > -0: > -1: > > ISSAC did you vote ? if you do we get the required votes. > > If do the release, make sure you send the e-mails from an @apache.org > e-mail. >
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
Steve Hay wrote: I didn't vote because AFAIK I don't actually have a vote. I have commit access, but I'm not a PMC member and therefore have no vote. Is that correct? You're not ? mumble grumble. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Director IT - RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
- Original Message > From: Steve Hay > To: Issac Goldstand > Cc: APREQ List > Sent: Wednesday, January 7, 2009 8:54:48 AM > Subject: RE: [RELEASE CANDIDATE] libapreq 1.34-RC4 > > I didn't vote because AFAIK I don't actually have a vote. I have commit > access, but I'm not a PMC member and therefore have no vote. Is that > correct? Everybody gets a vote ;-), but the ones that count towards the release requirements come from the httpd PMC. Here's my +1 for release Issac.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
Yay! That makes just a 1.5 year release cycle ;) I hope to release today after work. Who's got CPAN karma and voulenteers to help me upload? Joe Schaefer wrote: - Original Message From: Steve Hay To: Issac Goldstand Cc: APREQ List Sent: Wednesday, January 7, 2009 8:54:48 AM Subject: RE: [RELEASE CANDIDATE] libapreq 1.34-RC4 I didn't vote because AFAIK I don't actually have a vote. I have commit access, but I'm not a PMC member and therefore have no vote. Is that correct? Everybody gets a vote ;-), but the ones that count towards the release requirements come from the httpd PMC. Here's my +1 for release Issac.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
- Original Message > From: Issac Goldstand > To: Joe Schaefer > Cc: Steve Hay ; APREQ List > Sent: Wednesday, January 7, 2009 9:03:02 AM > Subject: Re: [RELEASE CANDIDATE] libapreq 1.34-RC4 > > Yay! That makes just a 1.5 year release cycle ;) > > I hope to release today after work. Who's got CPAN karma and > voulenteers to help me upload? For CPAN I recommend letting me do the upload, because none of us have control of the permissions for the apreq 1.x package names.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
Issac Goldstand wrote: Yay! That makes just a 1.5 year release cycle ;) Me. Thought i might be slow. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Senior Sys Admin- RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
On Jan 7, 2009, at 5:24 AM, Issac Goldstand wrote: *ping* I don't actually see a vote from Steeve - just an advisory that it seems OK. I did vote +1, and am ready to roll (after having a baby boy + getting the flu twice; it's been a busy month ;)) as soon as I see a 3rd binding vote. Since steevehay does seem positive, I'm going to start tagging and rolling, but won't upload or announce until I formally close the vote Issac I don't know if anyone has mentioned this before, but it is our policy to vote on completed artifacts, not "RC" tags or anything else that would be changed subsequent to the vote. Our goal is to verify that the finished tarball actually installs from source, and the only way to verify that is to have the signed tarball in hand before voting. In other words, you will have to call the vote again *after* rolling the actual releasable artifact. In the future, please do not ask people to vote on candidates -- it is a waste of time when we don't care how many version numbers are used between releases. Roy
Re: [VOTE] Unify release SVN tag, SVN branch and dating policy for 1.x and trunk
- Original Message > From: Issac Goldstand > To: APREQ List > Sent: Tuesday, November 11, 2008 4:16:06 AM > Subject: [VOTE] Unify release SVN tag, SVN branch and dating policy for 1.x > and trunk > > After reviewing the RELEASE files for 1.x and 2.x, I'd like to propose > that we clean them up a bit (though I don't forsee any more 1.3 > releases, we may as well get it in at the same time as 2.x) > > I won't summarize the current orders of operation (see [1] and [2]), but > here's what I'd like to see happen: > > 1) Create a release branch 1.x/2.x in /branches/ > 2) In trunk, modify the CHANGES and STATUS files to reflect a new dev cycle > 3) From the branch, prep the release for CPAN (don't forget to #undef > the APREQ_VERSION_IS_DEV macro definition). Test. Upload. Vote. > Repeat if needed. > 4) AFTER the release is approved by the PMC, modify the RELEASE and > STATUS files on branch + commit. Modify in trunk + commit. The way it should work IMO is to do whatever needs doing on the branch, including filling in the dates (a few days in advance) on the RELEASE and STATUS files, and then generate the tarball + sig and put that pair up for vote. If the vote doesn't pass by the dates you used, the vote fails and that version is an unreleased dud.
Re: [VOTE] Unify release SVN tag, SVN branch and dating policy for 1.x and trunk
Joe Schaefer wrote: - Original Message From: Issac Goldstand To: APREQ List Sent: Tuesday, November 11, 2008 4:16:06 AM Subject: [VOTE] Unify release SVN tag, SVN branch and dating policy for 1.x and trunk After reviewing the RELEASE files for 1.x and 2.x, I'd like to propose that we clean them up a bit (though I don't forsee any more 1.3 releases, we may as well get it in at the same time as 2.x) I won't summarize the current orders of operation (see [1] and [2]), but here's what I'd like to see happen: 1) Create a release branch 1.x/2.x in /branches/ 2) In trunk, modify the CHANGES and STATUS files to reflect a new dev cycle 3) From the branch, prep the release for CPAN (don't forget to #undef the APREQ_VERSION_IS_DEV macro definition). Test. Upload. Vote. Repeat if needed. 4) AFTER the release is approved by the PMC, modify the RELEASE and STATUS files on branch + commit. Modify in trunk + commit. The way it should work IMO is to do whatever needs doing on the branch, including filling in the dates (a few days in advance) on the RELEASE and STATUS files, and then generate the tarball + sig and put that pair up for vote. If the vote doesn't pass by the dates you used, the vote fails and that version is an unreleased dud. That sounds right and more in line with the normal httpd release procedure - that would mean doing (4) before (1) and leaving the rest as-is.
