On Thu, Oct 24, 2013 at 3:46 PM, Doug Cutting <cutt...@apache.org> 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
