Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # dev - [DISCUSS] What is the purpose of merge vote threads?


Copy link to this message
-
Re: [DISCUSS] What is the purpose of merge vote threads?
Tsz Wo \ 2013-10-25, 01:19
(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 <[EMAIL PROTECTED]> 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
> <[EMAIL PROTECTED]> wrote:
>>  > On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth
> <[EMAIL PROTECTED]>
>>  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