From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-council+bounces-593-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1MREc5-0005BF-SA
for garchives@archives.gentoo.org; Thu, 16 Jul 2009 00:14:18 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id F3BCBE00AB;
Thu, 16 Jul 2009 00:14:16 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id B0711E00AB
for <gentoo-council@lists.gentoo.org>; Thu, 16 Jul 2009 00:14:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with ESMTP id 5318564D73
for <gentoo-council@lists.gentoo.org>; Thu, 16 Jul 2009 00:14:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at gentoo.org
X-Spam-Score: -1.553
X-Spam-Level:
X-Spam-Status: No, score=-1.553 required=5.5 tests=[AWL=1.046,
BAYES_00=-2.599]
Received: from smtp.gentoo.org ([127.0.0.1])
by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id a-gWC5TLTtZr for <gentoo-council@lists.gentoo.org>;
Thu, 16 Jul 2009 00:14:10 +0000 (UTC)
Received: from ey-out-1920.google.com (ey-out-1920.google.com [74.125.78.144])
by smtp.gentoo.org (Postfix) with ESMTP id 135DD64EB0
for <gentoo-council@gentoo.org>; Thu, 16 Jul 2009 00:14:09 +0000 (UTC)
Received: by ey-out-1920.google.com with SMTP id 5so1033261eyb.6
for <gentoo-council@gentoo.org>; Wed, 15 Jul 2009 17:14:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:sender:received:in-reply-to
:references:date:x-google-sender-auth:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=eepmasDadoQADxXI8Nu7GBBCzt5MopONeLGe1h/VWcQ=;
b=Ccd2cYmstWglR4ZZS8ech5klclj4cBG0d7XpoJTuRWe6ZDlLdQp/ho2qOoC2uOJa2Z
/q+aMGHw0kCYHOUmEEXwoJyWBD60M2o8el7lYIjGDUfA3Z+dMvJ2N5qQKEo1qxyCdXEj
9g3JIVsP+Itw+Vcz6t7X5Do5l6NVav2yrdCfo=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:content-type
:content-transfer-encoding;
b=HQb5dOjv8ju1DiZ3MhLZ6O5+YQlZ9Vvk2tjmBk2D/0TyaH+5Zr2kSgpwV9CHJgEEZ1
jxCzTAo7cW1sNd/F+8QHchQt8N/VUtsWfQBZJeEcqv4lk6It2wxjSzfLEGMpbnVCbslH
isUQ7ByziwVAA7vkk7ZtmgPPFCPIGjrHmZEYM=
Precedence: bulk
List-Post: <mailto:gentoo-council@lists.gentoo.org>
List-Help: <mailto:gentoo-council+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-council+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-council+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-council.gentoo.org>
X-BeenThere: gentoo-council@lists.gentoo.org
MIME-Version: 1.0
Sender: denis.dupeyron@gmail.com
Received: by 10.216.48.195 with SMTP id v45mr2289054web.123.1247703249164;
Wed, 15 Jul 2009 17:14:09 -0700 (PDT)
In-Reply-To: <20090714233321.1cb0784f@anaconda.krait.us>
References: <7c612fc60907131606j10b1ef91k2a7882050c0527be@mail.gmail.com>
<20090714233321.1cb0784f@anaconda.krait.us>
Date: Wed, 15 Jul 2009 18:14:09 -0600
X-Google-Sender-Auth: 9c305a42873a6316
Message-ID: <7c612fc60907151714x1decb687rfcf81e41b837e17a@mail.gmail.com>
Subject: Re: [gentoo-council] Amending GLEP39
From: Denis Dupeyron <calchan@gentoo.org>
To: gentoo-council@lists.gentoo.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: f0d59490-78bd-4559-a331-4e89c0af709f
X-Archives-Hash: 59cc599ff4cddbdb3770879626916b49
On Tue, Jul 14, 2009 at 5:33 PM, Ferris McCormick<fmccor@gentoo.org> wrote:
> So it is conceivable that if council were to replace GLEP39, they would
> be working against the explicit wishes of the community.
The council is elected by the developer community to serve the
community's best interest. The developers chose the members they
wanted and could reject those they did not want. The way I understand
that is that all those who finished above the _reopen_nominations
level are to be considered trusted by a majority of the community.
Thus, your assumption that the council could be working against the
wishes of the community is equivalent to not trusting them, and in my
opinion should not be thrown into the equation.
> that is really a
> question for Grant (g2boojum) and Ciaran (ciaranm). =A0That would be
> primarily Grant, I think, because I asked ciaranm something about
> GLEP39 once, and as I recall, he told me that Grant was the primary
> author.
With all due respect to both of them, what they had in mind 4 years
ago matters much less than what we want to do for Gentoo in the
future. What they had in mind was influenced by the then situation and
a lot of things have changed. Grant and Ciaran are welcome to
participate to this discussion but I would prefer if you all gave your
own opinion on the matter, not theirs.
Anyway, as promised here's mine.
1- Yes, we can modify GLEP39. Gentoo is our project and we can make it
what we want. The only unknown is who and how.
2- GLEP39 was initially voted by all developers and is significant
enough that changes to it shouldn't be treated as lightly as any other
council decision.
3- The council members should be trusted by default and their smaller
number (compared to the whole developer community) enables a smoother
and faster decision process.
4- There is no way we will agree on how significant every change will
be, so we have to consider them all the same.
So what I would propose is that a unanimous decision from all 7
council members on each change warrants them to amend GLEP39. My
reasoning is that if all council members agree then it very likely
represents the opinion of the majority of developers who elected them,
and there's no point to resorting to an all-devs vote. In the case
where one or more member(s) would disagree then we have the natural
fallback to the process used for any other council decision: somebody
proposes that all developers vote on a change to GLEP39, and, after
discussion, if a majority of council members agree (either in a live
meeting or on the list) then we start the voting process.
This way we can maintain the smooth process for changes which seem
obvious enough, and we involve the whole developer community for less
obvious or more important decisions. And we don't have to decide in
advance how major or obvious a change is, the fact that we reach a
unanimous decision or not will speak for itself.
Denis.