-0. I abstain. On Wed, Feb 22, 2012 at 9:56 PM, Arvind Prabhakar <[email protected]>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 > > > -- Eric Sammer twitter: esammer data: www.cloudera.com
