On Wed, Jan 18, 2012 at 08:26:50AM -0600, Peter Karman wrote: > On 1/18/12 5:25 AM, Nick Wellnhofer wrote: > >> The attached patch addresses some of these points. In the auto generated >> changes list the new features are buried below bugfixes and >> improvements. I think they should go up front. > > Thanks for the patch, Nick.
+1 > We still need you to issue a VOTE on the RC. For the record, Nick did vote +1 on this RC already: http://s.apache.org/md > If you think the patch should be applied for the 0.3.0 release, then you > probably want to vote -1 and then we can re-roll a RC 2 with the patch. The individual who has the power to stop a release is the Release Manager. A release requires somebody to do the work (the RM) and a majority VOTE of the (P)PMC with a quorum of at least three +1s from (P)PMC members[1]. So... tallying the votes at this moment, we have +1 votes from myself, David, and Nick. Nick is free to change his vote, but that doesn't stop the release if somebody else from the (P)PMC (e.g. yourself once you get around to voting) adds a +1. I'm fine either way. The limited resource it might be good to conserve is Mentor time. Since none of our Mentors have voted yet, I don't think it's a big deal if we reroll. FWIW, if you do decide to cancel, I've seen people put "[VOTE][CANCELLED]" in the subject header of the email announcing the cancellation so that it's obvious what's happened. Another option, though, is to use the modified CHANGES entry in both the email announcing the release and in the CPAN tarball. That's what I'd advocate. Marvin Humphrey [1] http://www.apache.org/foundation/voting.html#ReleaseVotes
