-1 Sorry I missed the original discussion, but I feel that this makes the process more complicated for no real gain. In general we should be thinking about how to make it easier to contribute, not raising barriers for contributors and committers.
Why should a committer not be able to commit their own work after another committer has reviewed and +1'd it? (Which by my reading of the amendment would not be allowed.) I'm not convinced that changing the 3 day timeout to 6 will have a beneficial effect on the project. Have you got any cases where the current policy caused problems? Thanks, Tom On Wed, 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
