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
signature.asc
Description: Digital signature
