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