Actually, there is nothing wrong at all with a vote of -0.1. A +1 is a vote for and a -1 is a vote against. A +1000 counts as a +1 but means I reallly, really, really love this proposal. a -0.1 simply means he is slightly more opposed than against but it is still an abstention. A -0.9 would mean he really doesn't like the proposal but not enough to vote against it (this is far more typical to see on a vote over code where a -1 would be a veto). Think of it being similar to emoticons where this is pretty much the only way to express how you really feel.
Ralph On Feb 22, 2012, at 9:56 PM, Arvind Prabhakar wrote: > Thanks for your input Eric. Can you please choose one of the official > voting options? I am not sure if this vote is a -1 or a +0. > > Thanks, > Arvind Prabhakar > > On Wed, Feb 22, 2012 at 9:51 PM, Eric Sammer <[email protected]> wrote: > >> -0.1. >> >> I'm not at fan (at all) of a 6 day timeout but I understand the rationale. >> After thinking about this a bit, I also don't like the complexity of >> tracing authorship of changes (when the author is a committer) which this >> completely breaks. We absolutely need to ensure proper records are kept as >> to the original author of the patch. >> >> All of that said, Flume is a distributed system that people trust with >> their data and I think we need an insanely high bar for contribution. Of >> course, there's at least one major project at the ASF that I think has >> really poor implementation quality and they operate in RTC so I wonder >> about the efficacy. I'm torn and remain slightly against making the process >> even heavier (after some thought). I'm convincible (not that it's required >> that I be convinced if everyone feels otherwise). I trust the process. >> >> On Wed, Feb 22, 2012 at 9:28 PM, Ralph Goers <[email protected]> wrote: >> >>> +0 >>> >>> I'm not really a fan of RTC so this amendment doesn't impact much from my >>> point of view. >>> >>> Ralph >>> >>> >>> On Feb 22, 2012, at 2:38 PM, Arvind Prabhakar <[email protected]> wrote: >>> >>>> This is a call for VOTE to amend the existing RTC policy for Flume. For >>>> details of the stated policy and proposed amendment, see [1] and [2]. >> The >>>> discussion thread where this proposal was discussed is available at >> [3]. >>>> >>>> Please cast your votes: >>>> >>>> [ ] +1 Accept the proposed amendment to the stated RTC policy >>>> [ ] +0 Indifferent to the proposed amendment to the stated RTC policy >>>> [ ] -1 Reject the proposed amendment to the stated RTC policy. >>>> >>>> This vote will run for 72 hours. >>>> >>>> [1] Stated RTC policy: >>>> >>>> Code commits for all patches require: >>>> >>>> Lazy consensus of active committers but with a minimum +1 vote or 3 >> days >>>> >>>> passing with no comment. The code can be committed after the first +1 >> or >>>> >>>> after 3 days pass with no comment. >>>> >>>> If the code changes that represent a merge from a branch requires three >>>> +1s. >>>> >>>> >>>> Reference: http://markmail.org/thread/wfjpauoffz67k6ut >>>> >>>> >>>> [2] Proposed amendment: >>>> >>>> >>>> - All patches must require at lease one +1 vote from a committer. >>>> - A patch authored by a committer should be committed to the source >>>> control by another committer who +1s the patch during review. >>>> - First provision for no review commit: >>>> - If a patch authored by a committer is not reviewed within three >>>> days of submission, the patch author must request prioritization >> of >>> the >>>> review on the developer mailing list by other committers. >>>> - If another three days pass after a reminder and no one reviews >> the >>>> code, the committer may push the patch in. >>>> - If during any of this period a review is started by another >>>> committer, then no time-out applies and both the author must >>> address any >>>> suggestions and concerns as necessary to get a +1 by the reviewing >>>> committer. >>>> - Second provision for new review commit: >>>> - When cutting a release, the Release Manager will have the >>> authority >>>> to make commits to facilitate the release. Such commits should >> only >>> be to >>>> address build and other infrastructure requirements as needed for >>> the >>>> release. >>>> - Modifying a test or functionality necessary to cut a release >> would >>>> still require the regular review cycle and a minimum of one +1 >>>> from another >>>> committer. >>>> >>>> >>>> [3] Discussion thread for proposal: >>>> http://markmail.org/thread/ri5nigh42ugfg3zd >>>> >>>> Thanks, >>>> Arvind Prabhakar >>> >> >> >> >> -- >> Eric Sammer >> twitter: esammer >> data: www.cloudera.com >>
