[X] +1 Accept the proposed amendment to the stated RTC policy (non-binding)
On Wed, Feb 22, 2012 at 11: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 -- Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
