On Fri, Oct 25, 2013 at 10:56 AM, Vinod Kumar Vavilapalli <vino...@apache.org> 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
