RC2 for third_party.

[Andrew Bartlett]

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.

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.  

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.

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. 

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba