Tsz Wo \ 2013-10-25, 01:19
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 <
[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
> > On Thursday, October 24, 2013 5:09 PM, Tsz Wo Sze <[EMAIL PROTECTED]>
> > > 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
> > 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
> > the big patch in the mailing list. As review-commit, if the patch need
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.
Doug Cutting 2013-10-25, 17:18
Vinod Kumar Vavilapalli 2013-10-25, 17:56
Doug Cutting 2013-10-25, 19:04
Chris Nauroth 2013-11-07, 17:53
Chris Nauroth 2013-10-24, 20:40
Aaron T. Myers 2013-10-24, 21:07
Chris Nauroth 2013-10-24, 21:51
Doug Cutting 2013-10-24, 22:46
Aaron T. Myers 2013-10-25, 06:51