The only comment I have is that this just feels very "heavy". If we were using git instead of svn and the revisions could more easily be integrated perhaps it wouldn't seem so. However, this is the same comment I made regarding RTC in the first place so I'm not sure this changes anything in that regard.
Ralph On Feb 18, 2012, at 3:44 PM, 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
