The VOTE is now closed. I will be sending a RESULT mail separately. Thanks to all who voted.
Thanks, Arvind Prabhakar On Thu, Feb 23, 2012 at 3:43 PM, Mike Percy <[email protected]> wrote: > Hi folks, > As a very new contributor I was originally not going to chime in here, but > I've reconsidered. > > I am also concerned that this creates a heavier process. While it seems > likely that reviewers would often commit a patch they have +1'd, for > complicated cases like build overhauls as well as cases where other > committers are busy and don't have the time to commit a patch they have +1'd, > I think it seems reasonable to trust committers to properly commit their own > changes after approval. So I'd like to throw in in my own -1 (non-binding). > > Regards, > Mike > > On Feb 23, 2012, at 11:29 AM, Ralph Goers wrote: > >> Given this feedback I'm going to change my vote to a -1 also. As I recall I >> voiced concern for the length of time it takes to commit via RTC when it was >> first proposed so I'm not in favor of anything that makes it longer. >> >> Ralph >> >> On Feb 23, 2012, at 10:31 AM, Tom White wrote: >> >>> -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 >> >
