Hi Mike, The proposal to amend RTC policy was based on my experience in other projects so far, where I have observed such a policy to help build a stronger community. That said, please see my comments to your questions below:
> 1. Why would you want a second committer to have to commit > your changes if they already gave a +1? And how do you think > this could help keep more committers active on the project? There is not much difference between doing a review and doing a review and commit. The later does require you to have the latest codebase and be able to run tests before you checkin the patch. Committers do it all the time for contributions coming from community contributors. Having a uniform standard of accepting patches from contributors and committers alike promotes transparency in the project and helps the community thrive. > 2. Can you clarify how the below part of the proposed policy is different > from what is in place today? >> - 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. > The current policy requires at least one +1 in order to commit a patch. It does not explicitly state that a +1 from one committer does not bypass an on-going review from another committer. This part of the proposed amendment was to make this requirement explicit. In practice, I have not come across a situation where anyone has bypassed a reviewer once they have the necessary +1 from some other reviewer. Given that it is already a practice in our project, stating it explicitly would only make our governance model explicit and transparent. Thanks, Arvind Prabhakar On Thu, Feb 23, 2012 at 8:52 PM, Mike Percy <[email protected]> wrote: > Hi Arvind, > > I was out of town when this discussion thread went out, but looking back at > this discussion thread I didn't see called out a lot of specific reasons for > proposing these changes. I was wondering if you wouldn't mind relating why > you want to make some of these changes. For example: > > 1. Why would you want a second committer to have to commit your changes if > they already gave a +1? And how do you think this could help keep more > committers active on the project? > > 2. Can you clarify how the below part of the proposed policy is different > from what is in place today? >> - 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. > > > Regards, > Mike > > 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 >
