Re: [DISCUSS] What is the purpose of merge vote threads?

[Chris Nauroth <cn...@hortonworks.com>]

Thank you to everyone who replied.  Even though it sounds like there is not
complete consensus on some of the finer points, I think I have a clearer
understanding on how to participate now.

I do think posting all requirements in jira before calling the merge vote
makes the process more effective.  Contributors who haven't been following
the branch closely can get up to speed quickly by reading a refreshed
design doc and test plan.  Getting a +1 from Jenkins before the vote helps
reviewers focus on the logic instead of problems that could be caught by
static analysis.

Chris Nauroth
Hortonworks
http://hortonworks.com/



On Fri, Oct 25, 2013 at 12:04 PM, Doug Cutting <cu...@apache.org> wrote:

> On Fri, Oct 25, 2013 at 10:56 AM, Vinod Kumar Vavilapalli
> <vi...@apache.org> wrote:
> > Discussing on a voting thread is not productive.
>
> When all votes are +1 then no discussion is needed.  One shouldn't
> call a vote unless one expects all votes to be +1.  But, if
> unexpectedly they're not all +1, then a discussion must ensue, to
> substantiate the veto and to try to establish a remedy.
>
> It seems overly formal to immediately terminate all votes at the first
> expression of concern, restarting them later.  That puts process ahead
> of practicality and progress.  Rather, if an unforeseen yet easily
> addressed concern is raised during a vote then folks might reasonably
> agree to continue without restarting the vote.
>
> The purpose of the vote is to establish consensus.  If consensus is
> determined, then there's no need to delay.  So a vote can pass when
> the -1 voters change their vote to +1.  This might not hold if a
> remedy might be considered controversial, and its inclusion might
> reasonably invalidate prior +1 votes.  Then more time might be given
> for folks to consider the remedy.  But when the remedy is trivial it
> needn't be held to higher voting standard than a regular patch.
>
> Commits differ from releases since a release cannot be easily altered
> once published.  However a commit can be amended by subsequent
> commits.  We certainly want to minimize the need for subsequent
> commits, but don't need the same level of confidence.  With branch
> merge votes we should focus on the issue of whether the project is
> ready to assume the burden of maintaining the new functionality, since
> it's much harder to remove things than add them.  That's the reason
> for the one-week, 3 +1 rule.  For minor issues like compiler warnings,
> a fix to a merge patch should be held to the same standard as any
> other patch.
>
> Doug
>

-- 
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.