RC2 for third_party.

Simo simo at samba.org
Mon Aug 18 20:51:58 MDT 2014


On Tue, 2014-08-19 at 14:11 +1200, Andrew Bartlett wrote:
> On Mon, 2014-08-18 at 08:48 -0400, Simo wrote:
> > On Mon, 2014-08-18 at 09:29 +0200, Stefan (metze) Metzmacher wrote:
> > > Am 08.08.2014 um 22:04 schrieb Jeremy Allison:
> > > > On Sat, Aug 09, 2014 at 07:50:20AM +1200, Andrew Bartlett wrote:
> > > >>
> > > >> Please also remember to get metze's explicit ACK on this.
> > > 
> > > Thanks Andrew!
> > > 
> > > > That is not needed and it's inappropriate to request it.
> > > > Please don't try and speak on behalf of another Team
> > > > member. If Metze has issues I'm sure he can speak for
> > > > himself.
> > > 
> > > I already did, but it was completely ignored :-(
> > > 
> > > I thought I was pretty clear:
> > > https://lists.samba.org/archive/samba-technical/2014-July/101236.html
> > 
> > Sorry metze but asking for an explicit ACK is like putting a veto on
> > something, we have no rules to allow vetos from any team member, so I do
> > not think such requests have any standing when there are enough explicit
> > acks.
> 
> Simo,
> 
> This is a total distortion of how we have operated for a long time, and
> I remain very disturbed by the way this has been handled.

I've never seen a preemptive veto been thrown in before, I do not know
what you are talking about.

> If someone raises a specific concern in a review, and wants to be
> specifically consulted to verify the next change, this is entirely right
> and proper.  Metze put that very clearly, and he should have been
> consulted.
> 
> The alternative you advocate is 'review shopping', where if someone
> disagrees you just ask someone else who will agree.  

On technical changes a -1 can always be brought up, even after a change
was pushed. If you have a problem with the change that was made, on
technical grounds, please raise it and propose a revert.

> There was NOTHING about this that had to be rushed, and even less that
> meant that metze's views, which are generally held high regard, were not
> worth waiting for.

If you want to accuse Jeremy and Ira of review shopping, and trumping
someones veto and rushing code in, then please do so clearly, not with
passive aggressive mails to *me*.

I did not push the change, and was not involved in any way with it so I
am not sure why you are writing this in reply to me and with shouting
words.

> Sadly this text was lost when we removed MAINTAINERS.txt, but it still
> describes as best our practice in this area:
> 
> > The right of veto
> > -----------------
> > 
> > Over the last few years the Samba Team has started to use a +1/-1
> > voting system, which was inspired by the Apache voting system for
> > technical issues (see http://www.apache.org/foundation/voting.html).
> > 
> > For the maintainers proposal to work, I think we need to ensure that
> > everyone understands what a -1 "veto" vote means on a technical issue.
> > 
> > For purely technical issues, the +1/-1 voting system should not be a
> > "most votes wins" system. Instead a single -1 vote is supposed to
> > override any number of +1 votes, so a -1 vote is a "veto", and all
> > team members have the right to give a -1 veto vote on any purely
> > technical issue.
> > 
> > Along with the right to give a -1 veto vote comes the responsibility
> > to backup that veto with a technical argument, and the willingness to
> > then defend your argument in any subsequent discussions and to work
> > with the patch proposer to find a solution. If you do not backup your
> > -1 veto vote, or you are unwilling on unable to participate in any
> > discussions that arise from that veto, then the veto vote may be
> > disregarded.
> > 
> > Note that a veto is supposed to be used only for purely technical
> > reasons, so for example pointing out a security concern with a change,
> > or pointing out that the code may segfault or cause a regression of
> > functionality.
> 
> I would also note that it is also the responsibility of the promoter of
> a patch to work with the person who has made a veto.  
> 
> Even for changes as big as waf/autoconf, we have proceeded on this
> basis:  If you wish to change this now, we should make such a change
> deliberately, not by just pushing past the clearly stated view of
> others. 

A -1 vote on a technical detail with full explanation and defense of the
technical reason is quite different from a blanket preemptive veto.

Funny, though, that you bring up waf which many were absolutely not
happy with. Should someone have put a veto on it ? What do you think
would have happened if anyone tried ?

If you want that kind of veto power *you* are welcome to propose such a
change formally.

Simo.



More information about the samba-technical mailing list