From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 58B5F1381F3 for ; Mon, 24 Jun 2013 22:28:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7C6B3E0A4A; Mon, 24 Jun 2013 22:28:02 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D0434E0A49 for ; Mon, 24 Jun 2013 22:28:01 +0000 (UTC) Received: from [192.168.4.8] (blfd-4d08637f.pool.mediaWays.net [77.8.99.127]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id A567B335E31 for ; Mon, 24 Jun 2013 22:28:00 +0000 (UTC) Message-ID: <51C8C7EB.5090301@gentoo.org> Date: Tue, 25 Jun 2013 00:27:55 +0200 From: hasufell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130517 Thunderbird/17.0.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees) References: <51BF597B.6060600@gentoo.org> <51C7688A.2020103@gentoo.org> <51C77DD6.3090700@gentoo.org> In-Reply-To: <51C77DD6.3090700@gentoo.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Archives-Salt: 1aa7e879-5f37-49c7-9781-57ef83275b1f X-Archives-Hash: 0950f8b7c8fe4a81c7c4140d69eb4aac On 06/24/2013 12:59 AM, Rick "Zero_Chaos" Farina wrote: > On 06/23/2013 05:28 PM, hasufell wrote: > > @dberkholz > > > From your manifesto: > > >> I continue to believe that technical advances are, and should be, > >> driven by individuals. Given our volunteer culture, a council can't > >> force people to do things they don't want to do, but it can help > >> to break up disputes and roadblocks, and make global decisions when > >> needed. > > > Do you think that gentoo is consistent in it's behavior? > > > Should the council step in without any1 asking them if there are > > changes about to happen that are a) global and b) highly controversial > > discussed? > > > As an example: multilib. The council was not involved in that decision > > between eclass vs multilib-portage. Since any1 is allowed to add > > eclasses to the tree the decision was somehow implicit, without any > > real consensus on what the course should be. > > > > - From http://devmanual.gentoo.org/eclass-writing/ : > > "Before committing a new eclass to the tree, it should be emailed to the > gentoo-dev mailing list with a justification and a proposed > implementation. Do not skip this step — sometimes a better > implementation or an alternative which does not require a new eclass > will be suggested." > > The dev manual doesn't believe this is implicit nor without any > consensus. True, it doesn't ban you from adding a new eclass, but it > doesn't say you can just go and randomly add new eclasses without > discussion either. > > -Zero I know the devmanual quite well. The example in it's procedure was a bit more complex than you are describing, so I don't see how that adds anything. People agreed that the eclass is fine, but there was no real consensus about the question whether we actually want an eclass based solution. You can't have both, because it does not make sense. At one point you have to decide, council did nothing to aid in this heated (really heated) discussion.