couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: Voting -1 on the first sign of issues (was Re: [VOTE] Apache CouchDB 1.2.0 release, third round)
Date Tue, 27 Mar 2012 11:34:29 GMT
Also, everyone should vote, even if you've never spoken on this mailing
list before.

Every opinion is valuable, and is listened to.

On Tue, Mar 27, 2012 at 12:33 PM, Noah Slater <nslater@tumbolia.org> wrote:

> I disagree with this.
>
> It would be nice if people voting were able to assist, but the inability
> to assist SHOULD NOT prevent you from voting either way. If there are
> serious issues with the release, I want to know about them, and I WILL
> abort the vote for them.
>
>
> On Tue, Mar 27, 2012 at 12:21 PM, Dave Cottlehuber <dave@muse.net.nz>wrote:
>
>> On 26 March 2012 23:52, Noah Slater <nslater@tumbolia.org> wrote:
>> > As the person who's done the most tallying of votes over the last 4
>> years.
>> > I agree with Jan. Please leave your votes until you are reasonably sure
>> > they will not change. You CAN change them, but it is a PITA. Thanks!
>> >
>> > On Mon, Mar 26, 2012 at 6:43 PM, Jan Lehnardt <jan@apache.org> wrote:
>> >
>> >>
>> >> On Mar 26, 2012, at 19:34 , Sam Bisbee wrote:
>> >>
>> >> > On Sat, Mar 24, 2012 at 1:39 PM, Noah Slater <nslater@tumbolia.org>
>> >> wrote:
>> >> >> Thank you.
>> >> >>
>> >> >> Happy voting,
>> >> >>
>> >> >> N
>> >> >
>> >> > I'm having issues building the artifact on a brand new, vanilla
>> Debian
>> >> > 6.0 install (built fine on Ubuntu 11.10). It stops with the "can't
>> >> > find jsapi headers" error. Attached is my config.log.
>> >> >
>> >> > jsapi.h lives at /usr/lib/xulrunner-devel-1.9.1/include/jsapi.h as
>> >> > expected. Configuring without any parameters doesn't work either.
>> >> >
>> >> > So until I can debug this and update the wiki with any instructions,
>> >> > I'm -1 on the release.
>> >>
>> >> Hey all,
>> >>
>> >> I'd like to suggest that we might want to not vote -1 on the first
>> >> sign of issues.
>> >>
>> >> Of course we'd like to see any error report, but I feel it'd be nice
>> >> to wait for suggestions on how to fix this, rather than voting -1 or
>> >> voting -1 with a condition and later having to retract that.
>> >>
>> >> And if it turns out to be a grave error, a -1 is very much called for.
>> >>
>> >> Sorry for jumping on Sam here, but this has been done before and I
>> >> assume Sam just thinks it is standard procedure :)
>> >>
>> >> It might be me, but I know that tallying votes is less confusing with
>> >> definite votes.
>> >>
>> >> Please disagree with me, if you think we should continue with the
>> >> current practice :)
>> >>
>> >> Cheers
>> >> Jan
>> >> --
>> >>
>> >>
>>
>> It's worth taking a minute to read through the Apache guidelines:
>> http://www.apache.org/foundation/voting.html
>>
>> Specifically,  Votes on Package Releases
>> =\/=
>> Votes on whether a package is ready to be released use majority
>> approval -- i.e. at least three PMC members must vote affirmatively
>> for release, and there must be more positive than negative votes.
>> Releases may not be vetoed. Generally the community will cancel the
>> release vote if anyone identifies serious problems, but in most cases
>> the ultimate decision, lies with the individual serving as release
>> manager. The specifics of the process may vary from project to
>> project, but the 'minimum quorum of three +1 votes' rule is universal.
>> =/\=
>>
>> I think there's an unwritten expectation that if you're prepared to
>> vote you're prepared to assist on any issues uncovered.
>>
>> A+
>> Dave
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message