From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-83838-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by finch.gentoo.org (Postfix) with ESMTPS id 85AD81382C5
for <garchives@archives.gentoo.org>; Wed, 14 Feb 2018 15:40:54 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id EC7E1E0937;
Wed, 14 Feb 2018 15:40:42 +0000 (UTC)
Received: from mail-pg0-f41.google.com (mail-pg0-f41.google.com [74.125.83.41])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 89501E0933
for <gentoo-dev@lists.gentoo.org>; Wed, 14 Feb 2018 15:40:42 +0000 (UTC)
Received: by mail-pg0-f41.google.com with SMTP id o1so2065851pgn.4
for <gentoo-dev@lists.gentoo.org>; Wed, 14 Feb 2018 07:40:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to;
bh=PrhiV5NnAfK2AwP3I4J2NQyNI3vgynwZveny0H5vjkw=;
b=Q53YvJpb38VZfY1MsB8z1ZGOQcE0jqbxTkDQxdDoMecWth/oAFvvE+KaUh8oqdDskP
6gOtirO19im2JnnApNzU/kWXhXzRkCJNq8ivswPgtABZJlg7kMW39AZraMCyjeRlZRSC
JrSiQx0hQIUv+uuIm6MrixoKrjS2x80sI/z6PT3LY4XZlHrSK7kHyy8fHyrBKkXkDKdl
FQZh+9sVlZ3sfUIZdEOcHnS6d0L6vtjJ/kB/f5mKlTDpUhE2qxQTOBQLlE6K4SgAb3YV
dXYo/Z+/dUTD5J8KA5t/t7yaGsSmrfXxBFOAKWC/dEqVuKw1bieeTGG9wcwDdN1UD5Pp
1e8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to;
bh=PrhiV5NnAfK2AwP3I4J2NQyNI3vgynwZveny0H5vjkw=;
b=BRyOTXElwP1K+UN41oWRlAuKye2XlCQu5SjzLimSvRwaR997vsHog5faphf76A5A5h
UkefQaU98zkN9N6AyvCbdKmEv5Ac1gFCJZK2GGJlYX/tWm7yNkA3WtM2cO4mU+vrV/I8
rmYl/xFVxnNtB5LnoD1PycxGrvCeYcZHZi1e9nOlQgrdn+QAmLZZL8tOtZ0ecVumVBAT
X8jf3Yzt7dtR+fOCVi2vUhVdOAlLRw+VWCVcgQ1rzC5H+yocs6IWaAl6HFjWnSnJhK1G
37NUrQ6dZaam8vGhJ4VuY9fbZlmRiN997uKhfoWgQFEvEC+1AuoL6BPH2yg8jbqKpvYl
ddxw==
X-Gm-Message-State: APf1xPAJ5TzFnG1jCTrC2qt5+c19yj2ahTPhJrefJfRJsv46Ic8r3wHM
ZdZKBNmX2A8OgdynYb4ZvMCoQeDvZj/TvDFjVjb8x0w6
X-Google-Smtp-Source: AH8x226yvIEoREFNt0VEP2lExgpSYK8Si9WfKSdKAVJEmo5fw7Lne1ALC3kI8cssjkWcR9mzunaHyk7mSluElz/kQPg=
X-Received: by 10.98.32.136 with SMTP id m8mr4812027pfj.80.1518616781172; Wed,
14 Feb 2018 05:59:41 -0800 (PST)
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
Sender: freemanrich@gmail.com
Received: by 10.100.134.1 with HTTP; Wed, 14 Feb 2018 05:59:40 -0800 (PST)
In-Reply-To: <23171.27241.311990.19309@a1i15.kph.uni-mainz.de>
References: <20180211224234.GB6747@linux1.home> <23169.22344.839501.980448@a1i15.kph.uni-mainz.de>
<dea7c013-bfcd-e0ef-cc53-17d6f810039e@gentoo.org> <bf8e27d5-ea4a-b419-ccac-3ce8fbcbf450@gentoo.org>
<f4781100-3fa2-170f-c388-d53f353bf914@gentoo.org> <23171.27241.311990.19309@a1i15.kph.uni-mainz.de>
From: Rich Freeman <rich0@gentoo.org>
Date: Wed, 14 Feb 2018 08:59:40 -0500
X-Google-Sender-Auth: mbd56IsmW_oNVIywZGtyZUIGGzg
Message-ID: <CAGfcS_=bDrovLsiwS2k3qtktQ-BfaW54PGwbzsrDt3GzfKVvoQ@mail.gmail.com>
Subject: Re: [gentoo-dev] Re: [gentoo-project] rfc: council members and appeals
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Content-Type: text/plain; charset="UTF-8"
X-Archives-Salt: aed9eea4-880b-42b3-b17f-6bc089f4f78e
X-Archives-Hash: 6d026b5a86489c464b86f0068557a260
On Tue, Feb 13, 2018 at 5:44 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> At least for QA this is quite an oversimplified description of the
> team's role. Quoting GLEP 48, first bullet point of the specification:
> "The QA team's purpose is to provide cross-team assistance in keeping
> the tree in a good state. This is done primarily by finding and
> pointing out issues to maintainers and, where necessary, taking direct
> action."
>
I would suggest that if for whatever reason we do want to impose
further restrictions on Comrel membership, that we consider that these
may not be as necessary for QA membership.
A key difference between the two groups is that as far as I'm aware
all QA actions are completely public. If there is an issue everybody
can see that it exists, and take whatever action needed to correct it.
With Comrel there is more of a need to trust the individuals involved,
since the proceedings are not as transparent.
One thing I would suggest doing in general is to apply the same rules
to the Comrel lead as to the QA lead:
* The QA team is directed by a lead, chosen yearly by private or
public election among the members of the team, and confirmed by the
council. The QA team lead can choose one member as a deputy. The
deputy has all of his powers directly delegated from the QA team lead
and thus his actions and decisions should be considered equal to those
of the QA team lead. The deputy is directly responsible only to the QA
team lead.
* The QA lead's term expires one year after confirmation, and during
any period that the position is vacant the council may appoint an
interim lead.
Applying the same rules to Comrel would give it a bit more of a
mandate, though if the goal is some kind of independence from the
Council this policy would in fact reduce it. I personally don't like
having multiple leadership teams in Gentoo that do not have any kind
of hierarchy, because it can lead to sustained conflict. So, given a
choice of a directly-elected Comrel or a Comrel appointed by Council
I'd prefer the latter.
Part of me wonders if a lot of this debate is really a proxy for a
different debate: whether Comrel ought to be more or less active. If
you're a fan of Comrel being less active then you'd want a Comrel and
Council that largely disagreed, because it meant that any action taken
by the one would probably be undone by the other, and to the degree
that members of one can't serve on the other causes manpower issues,
so much the better. If you're a fan of Comrel being more active then
you'd want to ensure that only seriously flawed actions get undone,
and you would want to ensure that Comrel is well-manned.
Finally, I'd just like to note that as far as I'm aware there have
only been two appeals of Comrel decisions in the time I served on the
council (a number of years) and in both cases the decisions were
upheld despite all Comrel members recusing themselves from votes.
Comrel actions historically have been rare, and recusal vs non-recusal
wouldn't have made any difference (to do so the Comrel members would
have had to have voted against the previous Comrel decisions). That
isn't necessarily a reason to not have this discussion, but IMO in
practice this hasn't been much of a historical problem.
--
Rich