(Resend) No. In the past, committers would merge a branch once the merge vote had been passed even there were problems in the branch. Below is my understanding of merge vote.
Feature branch merge votes is the same as the traditional code review-commit process except that it requires three +1's and it happens in the mailing list. For review-commit, we +1 on the patch. If we think that the patch needs to be changed, we should ask the contributor posting a new patch before +1. This is not strictly enforced. In some cases, committers may say something like "+1 once X and Y have been fixed". In some worse cases, a committer may has committed a patch without +1 and then his friend committer will say "I mean +1 by my previous comment but I forgot to post it. Sorry, here is my +1." For merge vote, it should be considered that a big patch is generated by the diff from the branch over trunk. Then, committers vote on the big patch in the mailing list. As review-commit, if the patch need to be changed, committers should not +1 on it. Unfortunately, it is generally hard to review big patches and it is relatively easy to sneak bad code in. Both review-commit and merge vote are similar to voting on release candidates -- we vote on the bits of the candidate but neither vote on an idea nor a plan. (Of course, there are other types of vote for voting on a plan.) Regards, Tsz-Wo > On Thursday, October 24, 2013 5:09 PM, Tsz Wo Sze <szets...@yahoo.com> wrote: > > No. In the past, committers would merge a branch once the merge vote had > > been > passed even there were problems in the branch. Below is my understanding of > merge vote. > > Feature branch merge votes is the same as the traditional code > review-commit process except that it requires three +1's and it happens in > the mailing list. For review-commit, we +1 on the patch. If we think > that the patch needs to be changed, we should ask the contributor > posting a new patch before +1. This is not strictly enforced. In some > cases, committers may say something like "+1 once X and Y have been > fixed". In some worse cases, a committer may has committed a patch > without +1 and then his friend committer will say "I mean +1 by my > previous comment but I forgot to post it. Sorry, here is my +1." > > For merge vote, it should be considered that a big patch is > generated by the diff from the branch over trunk. Then, committers vote on > the big patch in the mailing list. As review-commit, if the patch need to be > changed, > committers should not +1 on it. Unfortunately, it is generally hard to > review big patches and it is relatively easy to sneak bad code in. > > > Both review-commit and merge vote are similar to voting > on release candidates -- we vote on the bits of the candidate but neither > vote > on an idea nor a plan. (Of course, there are other types of vote for voting > on > a plan.) > > Regards, > Tsz-Wo > > > > >> On Thursday, October 24, 2013 3:46 PM, Doug Cutting > <cutt...@apache.org> wrote: >> > On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth > <cnaur...@hortonworks.com> >> wrote: >> >>> When the voting happens on jira with a finalized merge patch, I know >>> exactly what I'm voting for, because it's the same >> review-and-commit >>> process that we follow every day with the extra requirement of 3 +1s. > When >>> it happens on email, it's less clear to me exactly what I'm > voting >> for. >> >> Here's my take, FWIW. The entire project needs to determine whether >> it is willing to take on the maintenance of code developed in a >> branch. This vote needs the widest audience. On the other hand, >> discussion on the umbrella Jira for the branch concerns the precise >> details of the merge commit. Even if the project is generally willing >> to accept maintenance of the code in a branch, committing it should >> not break the build that day. So fine-tuning the precise details of >> the merge often happens in Jira rather than as a part of the formal >> merge vote. Sometimes these are determined in parallel. >> >> Since a -1 must always be accompanied by a rationale, it should be >> clear whether such a vote concerns a fine point of the specific patch >> that's easily corrected or whether it's about a fundamental problem >> with the branch that will take longer to address. Either sort might >> be cast in either place. A fine-point objection shouldn't reset >> voting clocks and a fundamental objection concerns things that cannot >> be fixed in a voting window. If something lies in the middle then >> should be discussion until consensus is reached about whether the >> merge date need be delayed, voting restarted later, etc. I don't see >> a need for a more rigid policy here since we haven't seen things >> running amok around branch merges due to a lack of policy. >> >> Is that consistent with other folks understanding? >> >> Doug >> >
