+1 On Tue, Jul 12, 2011 at 12:56 AM, Aaron T. Myers <[email protected]> wrote:
> +1 from me as well. > > Thanks for running this vote, Jakob. > > Aaron > > On Jul 11, 2011, at 7:44 PM, Jakob Homan <[email protected]> wrote: > > > +1 to Eli's wording. > > > > On Mon, Jul 11, 2011 at 5:41 PM, Eli Collins <[email protected]> wrote: > >> +1 Sounds good to me. > >> > >> Something like the following? > >> > >> Index: main/author/src/documentation/content/xdocs/bylaws.xml > >> ================================================================== > >> <p>Lazy consensus of active committers, but with a minimum > of > >> - one +1. The code can be committed after the first > +1.</p></li> > >> + one +1. The code can be committed after the first +1, > unless > >> + the code change represents a merge from a branch, in which > case > >> + three +1s are required.</p></li> > >> > >> > >> > >> > >> On Mon, Jul 11, 2011 at 5:11 PM, Jakob Homan <[email protected]> wrote: > >>> As discussed in the recent thread on HDFS-1623 branching models, I'd > >>> like to amend the bylaws to provide that branches should get a minimum > >>> of three committer +1s before being merged to trunk. > >>> > >>> The rationale: > >>> Feature branches are often created in order that developers can > >>> iterate quickly without the review then commit requirements of trunk. > >>> Branches' commit requirements are determined by the branch maintainer > >>> and in this situation are often set up as commit-then-review. As > >>> such, there is no way to guarantee that the entire changeset offered > >>> for trunk merge has had a second pair of eyes on it. Therefore, it is > >>> prudent to give that final merge heightened scrutiny, particularly > >>> since these branches often extensively affect critical parts of the > >>> system. Requiring three binding +1s does not slow down the branch > >>> development process, but does provide a better chance of catching bugs > >>> before they make their way to trunk. > >>> > >>> Specifically, under the Actions subsection, this vote would add a new > >>> bullet item: > >>> * Branch merge: A feature branch that does not require the same > >>> criteria for code to be committed to trunk will require three binding > >>> +1s before being merged into trunk. > >>> > >>> The last bylaw change required lazy majority of PMC and ran for 7 > >>> days, which I believe would apply to this one as well. That would > >>> have this vote ending 5pm PST July 18. > >>> -Jakob > >>> > >> > -- Connect to me at http://www.facebook.com/dhruba
