openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Proposal: How we should handle committer vetos and reverts in the future
Date Thu, 14 Feb 2013 22:31:43 GMT
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:

When a committ is vetoed, it should be reverted quickly.   Remember, a
veto is likely to come only after sufficient discussion on the list
for one or more committers to think a veto is justified.  So if there
was a just a simple misunderstanding then it would have already been
taken care of.  So when a veto comes we need to treat it seriously and
revert the change.

(Think of it this way:  If we treat a veto merely as "Let's discuss
this some more on the list but not take any actions right now" then we
don't really have a veto option. )

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
rocket science and does not require special knowledge:

svn merge -c -XXXXXX (where XXXXXX is the revision number of the
revision that introduced the change you want to revert)
svn ci

That's it.

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.

Then, if needed, continue the discussion, including alternative
approaches and solutions to satisfying the concerns of outstanding
vetos.  If the vetos are withdrawn, then the patch can go back in.
Again, this is a simple mechanical task.

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

And remember, a veto does not mean you are wrong.  It just means that
another committer, like yourself, has expressed serious concerns about
your change.  You should respect that concern and be willing to remove
the code until these concerns are addressed.


View raw message