+1 (non-binding) This is a very high standard for commits, even higher than hadoop (committers can commit their own changes). I think high standards are good, my only concern is whether it will slow the pace of progress too much. Should that occur we can always change the policy.
Cheers, Brock On Sun, Feb 19, 2012 at 1:41 AM, Jarek Jarcec Cecho <[email protected]> wrote: > Seems fine to me (contributor opinion). > > Jarcec > > On Sat, Feb 18, 2012 at 03:44:15PM -0800, Arvind Prabhakar 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 -- Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
