hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Srinivas <sur...@hortonworks.com>
Subject Re: [DISCUSS] What is the purpose of merge vote threads?
Date Fri, 25 Oct 2013 16:35:19 GMT
I agree with what Nicholas is saying.

Feature branch merge votes are similar to traditional review-commit process.
That means the code should be ready, and pass the Jenkins build tests.
Also similar to regular patches where one describes what changes the
patch brings, having an updated design document (with change history
for the updates made to the design) helps people understand the design.
Updated user document for the feature helps end users to understand how the
feature works and helps them participate in testing. Finally, as expected
by every patch, we should have unit tests and also details of manual tests
done (with test plan for a feature).

This helps people participate in the voting/review more effectively.

There can be exceptions to the above list and some of the work could be
deferred. That could be captured in the jira, with the plan of how that
work gets done later. In such cases in the past we had
deferred merging the feature from trunk to a release branch until the work
was completed in trunk.

Granted some of the feature readiness activity can be done during voting.
But I fail to understand why expediting a feature that takes months to build
should try to optimize a week. Why not finish the requirements we have for
every patch for feature branch also?


On Thu, Oct 24, 2013 at 6:19 PM, Tsz Wo (Nicholas), Sze <
s29752-hadoopdev@yahoo.com> wrote:

> (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 <szetszwo@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
> > <cutting@apache.org> wrote:
> >>  > On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth
> > <cnauroth@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
> >>
> >
>



-- 
http://hortonworks.com/download/

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message