Re: [DISCUSS] What is the purpose of merge vote threads?
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 wrote: > On Fri, Oct 25, 2013 at 10:56 AM, Vinod Kumar Vavilapalli > 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.
Re: [DISCUSS] What is the purpose of merge vote threads?
On Fri, Oct 25, 2013 at 10:56 AM, Vinod Kumar Vavilapalli 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
Re: [DISCUSS] What is the purpose of merge vote threads?
It seems that overall the branch-merge voting threads are overloaded with multiple goals. Like other things that we vote on, a DISCUSS/PROPOSAL thread upfront for the branch-merge should alleviate any concerns that any committer might have. Once that is done, [VOTE] thread can simply be a formality of running tests, commiter +1s etc. Discussing on a voting thread is not productive. Thanks, +Vinod On Oct 25, 2013, at 10:18 AM, Doug Cutting wrote: > On Fri, Oct 25, 2013 at 9:35 AM, Suresh Srinivas > wrote: >> 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? > > I agree that requirements should not be relaxed. But different clocks > can be used for different kinds of concerns. For example, compiler > warnings should be addressed before commit but probably shouldn't > require restarting a week-long vote. The point of the week is to give > folks ample time to review a patch. Once concerns raised are > addressed to the satisfaction of those who've raised them why would > more time be required? However if someone asks for more time to > review because the changes they requested are not easily reviewable in > the time remaining then they should be given that time. Lastly, if > syncing a branch with trunk is difficult as trunk changes, then there > may be costs to delaying and we shouldn't delay without reason. > > 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. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [DISCUSS] What is the purpose of merge vote threads?
On Fri, Oct 25, 2013 at 9:35 AM, Suresh Srinivas wrote: > 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? I agree that requirements should not be relaxed. But different clocks can be used for different kinds of concerns. For example, compiler warnings should be addressed before commit but probably shouldn't require restarting a week-long vote. The point of the week is to give folks ample time to review a patch. Once concerns raised are addressed to the satisfaction of those who've raised them why would more time be required? However if someone asks for more time to review because the changes they requested are not easily reviewable in the time remaining then they should be given that time. Lastly, if syncing a branch with trunk is difficult as trunk changes, then there may be costs to delaying and we shouldn't delay without reason. Doug
Re: [DISCUSS] What is the purpose of merge vote threads?
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 < s29752-hadoop...@yahoo.com> wrote: > (Resend) > > 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 > plan.) > > Regards, > Tsz-Wo > > > > > > On Thursday, October 24, 2013 5:09 PM, Tsz Wo Sze > 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 plan.) > > > > Regards, > > Tsz-Wo > > > > > > > > > >> On Thursday, October 24, 2013 3:46 PM, Doug Cutting > > wrote: > >> > On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth > > > >> wrote: > >> > >>> 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. > >> > >> Here's my take, FWIW. The entire project needs to det
Re: [DISCUSS] What is the purpose of merge vote threads?
On Thu, Oct 24, 2013 at 3:46 PM, Doug Cutting wrote: > Here's my take, FWIW. The entire project needs to determine whether > it is willing to take on the maintenance of code developed in a > branch. This vote needs the widest audience. On the other hand, > discussion on the umbrella Jira for the branch concerns the precise > details of the merge commit. Even if the project is generally willing > to accept maintenance of the code in a branch, committing it should > not break the build that day. So fine-tuning the precise details of > the merge often happens in Jira rather than as a part of the formal > merge vote. Sometimes these are determined in parallel. > > Since a -1 must always be accompanied by a rationale, it should be > clear whether such a vote concerns a fine point of the specific patch > that's easily corrected or whether it's about a fundamental problem > with the branch that will take longer to address. Either sort might > be cast in either place. A fine-point objection shouldn't reset > voting clocks and a fundamental objection concerns things that cannot > be fixed in a voting window. If something lies in the middle then > should be discussion until consensus is reached about whether the > merge date need be delayed, voting restarted later, etc. I don't see > a need for a more rigid policy here since we haven't seen things > running amok around branch merges due to a lack of policy. > > Is that consistent with other folks understanding? > +1, I agree with all of this, and this is how I've always understood the merge vote process myself. Best, Aaron
Re: [DISCUSS] What is the purpose of merge vote threads?
(Resend) 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 plan.) Regards, Tsz-Wo > On Thursday, October 24, 2013 5:09 PM, Tsz Wo Sze 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 plan.) > > Regards, > Tsz-Wo > > > > >> On Thursday, October 24, 2013 3:46 PM, Doug Cutting > wrote: >> > On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth > >> wrote: >> >>> 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. >> >> Here's my take, FWIW. The entire project needs to determine whether >> it is willing to take on the maintenance of code developed in a >> branch. This vote needs the widest audience. On the other hand, >> discussion on the umbrella Jira for the branch concerns the precise >> details of the merge commit. Even if the project is generally willing >> to accept maintenance of the code in a branch, committing it should >> not break the build that day. So fine-tuning the precise details of >> the merge often happens in Jira rather than as a part of the formal >> merge vote. Sometimes these are determined in parallel. >> >> Since a -1 must always be accompanied by a rationale, it should be >> clear whether such a vote concerns a fine point of the specific patch >> that's easily corrected or whether it's about a fundamental problem >> with the branch that will take longer to address. Either sort might >> be cast in either place. A fine-point objection shouldn't reset >> voting clocks and a fundamental objection concerns things that cannot >> be fixed in a voting window. If something lies in the middle then >> should be discussion until consensus is reached about whether the >> merge date need be delayed, voting restarted later, etc. I don't see >> a need for a more rigid policy here since we haven't seen things >> running amok around branch merges due to a lack of policy. >> >> Is that consistent with other folks understanding? >> >> Doug >> >
Re: [DISCUSS] What is the purpose of merge vote threads?
On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth wrote: > 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. Here's my take, FWIW. The entire project needs to determine whether it is willing to take on the maintenance of code developed in a branch. This vote needs the widest audience. On the other hand, discussion on the umbrella Jira for the branch concerns the precise details of the merge commit. Even if the project is generally willing to accept maintenance of the code in a branch, committing it should not break the build that day. So fine-tuning the precise details of the merge often happens in Jira rather than as a part of the formal merge vote. Sometimes these are determined in parallel. Since a -1 must always be accompanied by a rationale, it should be clear whether such a vote concerns a fine point of the specific patch that's easily corrected or whether it's about a fundamental problem with the branch that will take longer to address. Either sort might be cast in either place. A fine-point objection shouldn't reset voting clocks and a fundamental objection concerns things that cannot be fixed in a voting window. If something lies in the middle then should be discussion until consensus is reached about whether the merge date need be delayed, voting restarted later, etc. I don't see a need for a more rigid policy here since we haven't seen things running amok around branch merges due to a lack of policy. Is that consistent with other folks understanding? Doug
Re: [DISCUSS] What is the purpose of merge vote threads?
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 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 >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 >
Re: [DISCUSS] What is the purpose of merge vote threads?
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 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. >
[DISCUSS] What is the purpose of merge vote threads?
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.