groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cedric.champ...@gmail.com>
Subject Re: [VOTE] Support Java-like array
Date Tue, 15 May 2018 06:07:04 GMT
I can say why I didn't vote: I didn't have time to review the proposal and
its consequences, so I don't want to give a blind +1 or -1.

Le mar. 15 mai 2018 à 08:03, mg <mgbiz@arscreat.com> a écrit :

> What I meant to say yesterday at 1am was: "On the other hand I do not get
> why only 2 PMC members have been voting +1 on this proposal..."
>
> This is not against voting +0, but about why so few PMC members vote at
> all... (?)
>
> -------- Ursprüngliche Nachricht --------
> Von: MG <mgbiz@arscreat.com>
> Datum: 15.05.18 00:57 (GMT+01:00)
> An: dev@groovy.apache.org, Paul King <paulk@asert.com.au>
> Betreff: Re: [VOTE] Support Java-like array
>
> My 10 cents:
> [VOTE][LAZY] seems a bit odd - if PMC members are on vacation/ill/afk one
> person could basically push through sweeping changes, which seems odd.
> On the other had I do not get why only 2 PMC members have been voting on
> this proposal - if you do not care either way, and it already has 2 x +1,
> just push it over the edge, if you are really against it, shoot it down
> with -1...
> Cheers,
> mg
>
>
> On 13.05.2018 10:57, Paul King wrote:
>
> My understanding is that there is some flexibility when asking for votes
> so long as it is clear up front what the expectation is, see e.g. [1]. Even
> though there are numerous generic Apache sites with similar descriptions, I
> was thinking of adding some more content in some of our pages to summarise
> the most relevant information for our project. I was thinking of some
> additional wording to the "Contributing code" section of the website to
> indicate that typically committers should be following the same guidelines
> (creating PRs etc.) for any significant code change as for people without
> committer status. Also, I was going to add some wording somewhere around
> our typical conventions for voting. Something like:
>
> We strongly value keeping consensus within the project. Sometimes
> consensus is obvious from general discussions or informal +1s in PRs or
> Jira issues. For significant changes within PRs or Jiras, it is good to
> send an informational to the dev mailing list in any case. When consensus
> is not obvious or for potentially contentious changes, emails with a [VOTE]
> in the subject line are a good way to ascertain consensus. Typical
> scenarios are:
> * [VOTE] for a release - requires 3 more binding +1 votes than -1 votes
> (no veto capability)
> * [VOTE] for code change - requires 3 binding +1s but can be vetoed with a
> single -1 binding vote
> * [VOTE][LAZY] for code change - assumes absence of a vote is a +1 (but
> you'd normally want at least one binding +1 so best to wait a bit longer if
> you don't have at least one) but can be vetoed with a single -1 binding vote
> A committer creating a PR request is similar to [VOTE][LAZY].
> 72 hours is the minimum for such votes but there is no maximum time delay
> - though waiting too long isn't a good idea since the circumstances which
> lead to earlier +1s might have changed.
>
> If anyone has improvements for this wording, let me know.
>
> [1] https://www.apache.org/foundation/voting.html
>
> Cheers, Paul.
>
> On Sun, May 13, 2018 at 2:20 PM, Remko Popma <remko.popma@gmail.com>
> wrote:
>
>> That’s probably why over at Log4j we use slightly different language for
>> voting:
>>
>> “The vote will remain open for 72 hours (or more if required). At least 3
>> +1 votes ...”
>>
>> It seems unfair that by not participating, it is possible to essentially
>> vote -0 or -1 without justification...
>>
>> Thoughts?
>>
>> Remko
>>
>> > On May 13, 2018, at 11:48, Daniel.Sun <sunlan@apache.org> wrote:
>> >
>> > Please see my original email:
>> > "The vote is open for the next 72 hours and passes if a majority of at
>> least
>> > three +1 PMC votes are cast."
>> >
>> > Cheers,
>> > Daniel.Sun
>> >
>> >
>> >
>> >
>> > --
>> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>
>
>

Mime
View raw message