Thanks for pointing this out. I hadn't seen it, but I just caught up.
This proposal states that 3 binding +1 votes are required for a branch
merge, which makes sense to me. My confusion arises from the fact that
I've seen the voting happening in 2 different places in 2 different ways
simultaneously: either directly on the jira with a finalized merge patch or
in an email thread. In the latter case, the process hasn't been
consistent. Sometimes the finalized merge patch is posted before the vote
begins, and sometimes the proposal comes with a dev plan describing
remaining work intended to be finished before the merge.
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.
Whether the relevant voting happens on jira or email, this all comes down
to process questions around merges. To make this more specific, here are a
Is a 7-day voting period required? This isn't stated in the bylaws or the
Does the vote begin when the devs present a finalized merge patch, or can
the vote begin earlier with intent to finish a few things before the vote
If someone casts a binding -1, does that reset the clock on the vote?
If someone finds something that needs to be fixed, but doesn't cast a
binding -1, does that reset the clock on the vote?
On Thu, Oct 24, 2013 at 2:07 PM, Aaron T. Myers <[EMAIL PROTECTED]> wrote:
> Hi Chris,
> Have you read the original thread on general@ which added this to the
> bylaws? At the beginning of that thread, Jakob provided some rationale for
> the branch merge vote and requiring three +1s.
> Link to that vote thread here:
> http://mail-archives.apache.org/mod_mbox/hadoop-general/201107.mbox/%3CCADiKvVvYhSTSBDokOqvapu-OYUrVEtOC+[EMAIL PROTECTED]%3E
> The summary is roughly that because we might not adhere to the typical
> review process when committing to a branch (e.g. allowing non-committers
> binding +1s, or perhaps allowing CTR instead of RTC) that the act of
> merging in a development branch to trunk should require more scrutiny than
> just a single JIRA's worth of code change, and thus it's desirable to hold
> a separate merge vote which requires three +1s instead of the usual one.
> On Fri, Oct 25, 2013 at 5:40 AM, Chris Nauroth <[EMAIL PROTECTED]
> > I've realized that I'm very confused about the purpose and the process of
> > merge votes. I'd like to use this thread for clarification so that we
> > know exactly what our votes on a merge thread mean. It's possible that
> > we'll even want to reconsider whether or not merge vote threads are
> > From what I can tell, there is no concrete action taken as a result of a
> > merge vote thread. If the vote passes, nothing happens. If the vote
> > doesn't pass, nothing happens. Instead, it is the +1 vote on the merge
> > patch in jira that really drives action. This differs from all other
> > voting topics, which do result in some concrete action if passed (new
> > release, change to the bylaws, etc.). Considering that, what value do we
> > get from merge vote threads?
> > It seems the merge votes could be replaced entirely by the traditional
> > review and commit process. Committers can respond directly on the
> > jira with +1 (or -1 and a list of what needs to be done to earn a +1).
> > merge vote threads may in fact be detrimental, because they fork relevant
> > technical discussion away from the jira and into the mailing lists.
> > it be appropriate for us to say that the real merge vote happens on the
> > jira and do away with the process of conducting a separate vote on the
> > mailing list?
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.