james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Type of next release
Date Tue, 19 Dec 2006 13:00:36 GMT
> "real enhancement" is an opinion. IMO it is a bit too easy to label
> expressing different opinions as blocking.
> Well, if you just try again without coming to an agreement you're
> changes will be vetoed again for sure.

"for sure"? I think we cannot conclude that a veto is unescabable.
Vetos should happen rarely.
I agree that a veto is _more_likely_ to occur if no communication is happening.
But we do CTR, and a veto is only valid if a technical justification is given.
In general terms, it is not ok to use a veto or a threat to veto for
other means than that.

A -1 is not a veto beyond the technical aspect. A majority decision
cannot be vetoed, and as a consequence in particular a release cannot
be vetoed.

My understanding is also that a technical veto does not hold up
development. It only holds up a particular change. It is OK to say:
wait a second, let's resolve the veto at first so we can go on with
business immediately. But this is not binding.

Stefano said in a previous post:
> Reanimate the discussion and try to get more people involved by
> summarizing the problem. I guess no one will veto a majority decision.

You cannot veto a majority decision. Except code changes (commits) and
only with technical justification, where majorities do not apply. And
in this specific case of course a single person can indeed hold up all
the others. He cannot be overruled. This is the intention of the veto
instrument. Vetos have happend in the past and will happen again.

So I would like to remind all honourable fellow committers to use the
"veto" powers and even the word "veto" with great care.

Furthermore, let us resolve all vetos, now, today. Vetos are there to
be resolved and put aside, not to be "standing" or to be compared to
each other or used as a means of oppression. Thanks to Stefano, who
took heart and made an effort to resolve his.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message