From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-65525-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id C33451387FD
	for <garchives@archives.gentoo.org>; Tue,  1 Apr 2014 17:50:56 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id AF546E0ADB;
	Tue,  1 Apr 2014 17:50:49 +0000 (UTC)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id BE14DE0AC4
	for <gentoo-dev@lists.gentoo.org>; Tue,  1 Apr 2014 17:50:48 +0000 (UTC)
Received: by mail-vc0-f172.google.com with SMTP id la4so10161570vcb.17
        for <gentoo-dev@lists.gentoo.org>; Tue, 01 Apr 2014 10:50:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:sender:in-reply-to:references:date:message-id:subject
         :from:to:cc:content-type;
        bh=I4z4BILct/CZbX1FM3v8ixRn2DsirM648gypPknvRN4=;
        b=CnN9J454+LpQwCMTq246R1ZQw1rYCip4B6S/fLZ+zQxs5sKIzCqIbe0ZfBUzl2PCZ2
         PYXM3TYrXsMTz7kumS0bOcVosK6hzrZXrwf2E+buCp6igp4DrCy1Fo1bJ1eZGXxkskOj
         piuBPaac06562nxrPsUG+h2WgmLTUQqnN3tgrSfOdLyY9R6Gm4oErWlMrVY81Dzc6agP
         uyXthccSELRyAl7yXk9ZpoXZSPIGqx2LzAbJczNzSi6/lcdOIgg/GuqwvukV+Ip5ZFI8
         /AHLOeT8Ig9SuUkT4uiiwgQNOYHESoRzlbBFr+LnShMHHCtFLrqj22hpGjBS7wHb/Pkn
         Yv5Q==
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.52.125.170 with SMTP id mr10mr205247vdb.71.1396374647013;
 Tue, 01 Apr 2014 10:50:47 -0700 (PDT)
Sender: freemanrich@gmail.com
Received: by 10.52.29.142 with HTTP; Tue, 1 Apr 2014 10:50:46 -0700 (PDT)
In-Reply-To: <20140401172803.219a51fe@gentoo.org>
References: <5335EE26.1010606@gentoo.org>
	<53364874.9050603@gentoo.org>
	<53388280.4010105@gentoo.org>
	<53390215.80604@gentoo.org>
	<5339D180.2010309@gentoo.org>
	<533A5328.1000607@gentoo.org>
	<533AAFCF.9070600@gentoo.org>
	<20140401172803.219a51fe@gentoo.org>
Date: Tue, 1 Apr 2014 13:50:46 -0400
X-Google-Sender-Auth: Ubhxqm0qLUXBdGep-DqrcHssHS8
Message-ID: <CAGfcS_mjYrfA6iTpLhGJsAhfvurz1KtYf5K6P=N6r1vDvxPg1w@mail.gmail.com>
Subject: Re: [gentoo-dev] New virtuals for libudev and libgudev
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Cc: hasufell <hasufell@gentoo.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Archives-Salt: 47170bf4-8ed5-464b-a799-0e93ab02bb4a
X-Archives-Hash: 9bc30c28368a4827feab0965cff163d5

On Tue, Apr 1, 2014 at 11:28 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> There is a strong structure present; for policy enforcement and
> breakage prevention, we have the ability to 1) act until there is
> disagreement, 2) vote by majority, 3) elevate to deputy and/or lead.

So, rather than making statements of blame at this time, maybe I'll
just focus on general principles.

I'm sure there are opportunities for improvement in QA - there
certainly were when we reconstituted it back in the fall, and it
sounds like there has been progress which is great to hear.  I think
most if not all of us in the Council wanted to let the team recommend
its own policies (subject to Council approval where the GLEP is
concerned).  It would be great if these were posted/explained/etc, to
whatever degree they're complete.

If somebody feels they are the victim of a QA decision, contact
QA/Comrel/Council.  If somebody feels that they are the victim of a
decision being made in the name of QA which isn't really a QA
decision, contact QA/Comrel/Council.  If you just unilaterally
override a decision made in the name of QA, you had better have a
REALLY good reason for it, and I'm talking "QA accidentally introduced
an rm -rf /* command in pkg_postinst on an openrc bump and nobody
responded to my ping."  Making a mistake that is caught by QA is no
big deal - we live and learn.  QA making a mistake is a bigger deal,
but again we can live and learn.

There are probably lessons to be learned here all around, and I'm sure
the Council will be following up on all of them.  However, when there
is disagreement there are right and wrong ways to handle it.  Venting
on the list is understandable, even if we should be mindful of the
CoC.  Venting with "cvs commit" is dangerous - our users trust us to
exercise good judgement with anything that goes into the tree.  Revert
wars are simply unacceptable.

Members of QA/Council/etc are accountable to the developer community
collectively.  None of us get to exercise a personal veto on their
decisions.  If there is abuse, there is a right way to handle it.  If
you disagree with the powers QA is entrusted with, by all means
express this, but you must abide by QA decisions until appealed.
Nobody is going to get "disciplined" for making a mistake, real or
otherwise.

So, take all of that in general, and to the degree that you think it
applies, apply it to yourself.  If you do a particularly poor job of
applying it to yourself somebody in Comrel might do it for you. I
don't know all of what happened, so I won't directly cast blame here -
I don't know what exonerating circumstances might exist or what was
said to who privately in IRC.  However, this whole mess is definitely
going to be on the next Council agenda...

Rich