Since the discussion has settled on this proposal, I will go ahead and call a community vote on this.
Thanks, Arvind Prabhakar On Sat, Feb 18, 2012 at 3:44 PM, Arvind Prabhakar <[email protected]> wrote: > Hi, > > Soon after Flume entered the Apache Incubator, we discussed and > implemented a Review-Then-Commit policy for contributing towards the > project. Since that time, this policy has served as well and continues to > do so. The formal specification of this policy can be found in the email > below: > > http://markmail.org/thread/wfjpauoffz67k6ut > > Now that Flume has made its first release from the incubator, and the > number of contributors is starting to grow, I wish to propose a slight > revision to this policy. Specifically the revision being proposed will > amend the exiting policy as follows: > > - 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. > > Most of this provision is already part of the originally stated policy. > What this amendment does it to make explicit the requirement to have two > committers per patch that is authored by another committer. This will allow > us to balance our priorities and help keep more committers active on the > project. > > If you have any concerns regarding this amendment, please bring them up > for discussion on this thread. > > Thanks, > Arvind Prabhakar > > >
