RC2 for third_party.

[Andrew Bartlett]

On Mon, 2014-08-18 at 22:51 -0400, Simo wrote:
> 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.

I for one have asked for them in the past (on the widespread kerberos
changes for example). 

> > 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 am deeply unhappy with how this was handled, and have written so
multiple times.  I'm sorry of that is not clear to you, or to the others
involved. 

It is my strong desire that we stop at this point, until we have the
consensus we have been so proud in the past to operate on.  

> 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 ?

I made significant efforts to get a positive ACK from Volker on the
autoconf removal, and to his high credit, he gave it.  

In another mail in this thread I also described the way waf was handled
(particularly at the beginning) as unfortunate.  Please read that mail
for my full thoughts. 

Thanks,

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