On Thu, Feb 14, 2013 at 05:31:43PM -0500, Rob Weir wrote: > Obviously the changes to Calc's POWER() function did not go well. > > IMHO, we need to better respect the rare but powerful veto option that > committers have: > > http://www.apache.org/foundation/glossary.html#Veto > > When a committ is vetoed, it should be reverted quickly. Remember, a
No. This is flat out incorrect. A veto means you cannot *ship* with that change in there. It can stick around as long as necessary, but must eventually be pulled out when the code is shipped. There is no "quickly" about it. A veto means a start of a *discussion*. The discussion can end up with at least a few outcomes: * the committer realizes the problem, agrees, and reverts * the committer understands the (technical) concern, and modifies the change to address that concern * the veto-er learns more about the change and withdraws the veto In all of these cases, there is no mandate to revert. The veto has never in the course of the Founddation meant "revert now". It has meant "we need to talk about it; I have some concerns". >... > If the original coder is willing and able to revert quickly, then > great. But anyone, including the veto'er can do this. It is not No. This is anti-social. Given that there are multiple possible outcomes of the discussion, somebody deciding *unilaterally* to revert the change is doing just that: putting their decisions above those of the group's consensus. The correct result is to generate consensus on why the change was (technically) problematic, and to arrive at a solution. In most cases, the result is to make additional changes to resolve the technical problem. Taking a step back is *rarely* the answer, and an individual who unilaterally makes a decision for the group is being anti-social. >... > It is very likely that the person whose changes were vetoed will not > like the veto or the revert. That is quite natural. We all have > egos. None of us like having our changes rejected. We all have our > egos wrapped up in our code. That is why we cannot rely on the > original coder being the one to revert. We don't want to turn this > into a battle of wills between the person who made the change and the > person(s) who vetoed it. Put egos aside. A veto is not the > opportunity to escalate the argument. A veto is an opportunity to > isolate the controversial code where both sides can calmly discuss it, > knowing that there is no longer immediate concern in the main code. > And reversion is SVN is a simple mechanical act. It does not require > anyone special to do it. Any committer can do it. And this is not a "both sides" issue, but a community issue. A discussion starts. And the original committer should be the one to decide, based upon the discussion result. You talk about ego, and we all have them. The answer is to work with that fact, and come to a mutual decision. Not to slap another's ego in the face with unilateral decisions to alter the work that a person is attempting to perform. >... > The point of a veto and a quick reversion is to return the code base > quick to a state where it does not contain controversial changes in > it. That is NOT the point of a veto. A veto is "don't ship with that". The corollary actions are very, very different from what you suggest. About the *only* time when somebody should revert another's is when the build system becomes broken. That shuts down the entire community. Note: I'm not talking about test failures. Introducing a failure does not prevent the community from acting. But build breakages certainly can (at least, on default configurations; if the breakage is with an obscure config, then it could possibly be left in for a day or two to work out a proper solution). Joe pointed out the standard 72 hours. Shoot for that if you see some kind of build breakage, but if it is just too horrific, and it appears the committer has gone away for a while, then do the minimum possible to restore the build. Use a proper log message, and alert the original committer what you have done. Cheers, -g
