+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
