Hi Aaron, 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 few questions: Is a 7-day voting period required? This isn't stated in the bylaws or the original proposal. 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 concludes? 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? Chris Nauroth Hortonworks http://hortonworks.com/ On Thu, Oct 24, 2013 at 2:07 PM, Aaron T. Myers <a...@apache.org> 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+tcaqb2faqlisdw...@mail.gmail.com%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. > > Best, > Aaron > > > On Fri, Oct 25, 2013 at 5:40 AM, Chris Nauroth <cnaur...@hortonworks.com > >wrote: > > > 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 > all > > 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 > useful. > > > > 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 > code > > review and commit process. Committers can respond directly on the > umbrella > > jira with +1 (or -1 and a list of what needs to be done to earn a +1). > The > > merge vote threads may in fact be detrimental, because they fork relevant > > technical discussion away from the jira and into the mailing lists. > Would > > 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? > > > > Also, I don't see consistency in this process across sub-projects. Merge > > vote threads have been more frequent in HDFS than YARN. If we continue > to > > use merge vote threads, then do we need to do this consistently across > the > > sub-projects? > > > > My first inclination was to review the bylaws for clarification. The > > bylaws don't call out merges as a separate voting topic. Instead, merges > > just fall under Code Change with the extra requirement of 3 +1s from > > committers instead of 1. Again, this sounds like activity better suited > to > > the jira in question, where the proposed action is to commit a code > change, > > and committers and contributors enter comments to vote on acceptance of > the > > code and related artifacts like design docs and test plans. > > > > Of course, there may be a need to announce that a big feature is almost > > ready and needs more reviewers. That could be handled by an email to the > > dev lists, but I don't see the benefit of labeling that as a vote. Best > > case scenario, the vote is redundant with the more meaningful activity > > happening on the jira. Worst case scenario, the vote is a distraction > and > > introduces an artificial 7-day delay on code that has already received > > votes in jira. > > > > Until I get some clarification on this, I don't think I can participate > in > > further merge vote threads in good conscience. I'll continue to offer my > > +1 or -1 directly on feature jiras, where I know with certainty that I'm > > voting on whether or not to accept something tangible. > > > > Thank you! > > > > Chris Nauroth > > Hortonworks > > http://hortonworks.com/ > > > > -- > > 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. > > > -- 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.
