On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth <cnaur...@hortonworks.com> 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
