That's certainly not the intention, although I note that the current
+1 requirement on code changes would apparently allow a committer to
+1 h{is,er} own patch:
"A change made to a codebase of the project and committed by a
committer. This includes source code, documentation, website content,
etc. Lazy consensus of active committers, but with a minimum of one
+1. The code can be committed after the first +1."On Mon, Jul 11, 2011 at 5:17 PM, Todd Lipcon <[email protected]> wrote: > To clarify, is there any restriction on who may give the +1s? For example, > if a branch has a group of 5 committers primarily authoring the patches, can > the three +1s be made by a subset of those committers? > > -Todd > > 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 >> > > > > -- > Todd Lipcon > Software Engineer, Cloudera >
