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-dev+bounces-41831-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1OY4Vx-0006Jc-Uh
	for garchives@archives.gentoo.org; Sun, 11 Jul 2010 21:56:46 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 40974E0A8D;
	Sun, 11 Jul 2010 21:56:43 +0000 (UTC)
Received: from mail-vw0-f53.google.com (mail-vw0-f53.google.com [209.85.212.53])
	by pigeon.gentoo.org (Postfix) with ESMTP id EDA64E0940
	for <gentoo-dev@lists.gentoo.org>; Sun, 11 Jul 2010 21:56:32 +0000 (UTC)
Received: by vws15 with SMTP id 15so4009820vws.40
        for <gentoo-dev@lists.gentoo.org>; Sun, 11 Jul 2010 14:56:32 -0700 (PDT)
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
Received: by 10.220.121.144 with SMTP id h16mr6439061vcr.19.1278885392205; 
	Sun, 11 Jul 2010 14:56:32 -0700 (PDT)
Sender: cardoe@cardoe.com
Received: by 10.220.182.77 with HTTP; Sun, 11 Jul 2010 14:56:32 -0700 (PDT)
In-Reply-To: <4C39F356.1090200@gentoo.org>
References: <4C37A114.9070604@gentoo.org>
	<4C381392.5050505@gentoo.org>
	<20100710083437.GA6598@hrair>
	<20100710210258.2005f27c@gentoo.org>
	<AANLkTilTEmLbipmMCkQ_btTx7iMXfYxlKt1Dfs5DB2-t@mail.gmail.com>
	<4C39BDCE.3010602@gentoo.org>
	<AANLkTimtVdCdjavr7AizIb9K3N7uCxuXwO3yzF_N4bfp@mail.gmail.com>
	<4C39F356.1090200@gentoo.org>
Date: Sun, 11 Jul 2010 16:56:32 -0500
X-Google-Sender-Auth: VzuX-Gh37Y8rjkFOQF6xMqY8SfM
Message-ID: <AANLkTikEVBTSiY3DsdMfw-HkUBdgF0aUu7_si4EuP7El@mail.gmail.com>
Subject: Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others
From: Doug Goldstein <cardoe@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 18b72e54-ff76-4ff7-ae43-075ec25034cc
X-Archives-Hash: 8f85320959ff7e6ea759560b18b24896

On Sun, Jul 11, 2010 at 11:37 AM, Jorge Manuel B. S. Vicetto
<jmbsvicetto@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Doug.
>
> On 11-07-2010 16:03, Doug Goldstein wrote:
>> On Sun, Jul 11, 2010 at 7:49 AM, Petteri R=C3=A4ty <betelgeuse@gentoo.or=
g> wrote:
>>> On 07/11/2010 08:02 AM, Doug Goldstein wrote:
>>>
>>>> If I really need to go to the council with every change, considering
>>>> it must be debated on the ML for at least X number of days prior to
>>>> going to the council, I'd more likely just remove MythTV from the tree
>>>> and maintain it in an overlay. I don't invest a lot of time in the
>>>> MythTV ebuilds, but they work for a large majority of people. And when
>>>> a new version comes out it requires some retooling and it just works
>>>> for everyone.
>>>>
>>>
>>> When someone proposes this I'll let you know. What's under discussion i=
s
>>> allowing removals to the public API of eclasses by following a
>>> documented process (that doesn't involve council approval).
>>>
>>>> So basically, you guys decide.. am I pulling them out of the tree or
>>>> am I leaving them in?
>>>>
>>>
>>> If you decided to drop maintenance of MythTV in main tree, wouldn't it
>>> be a better service to users to try and find a new maintainer (who woul=
d
>>> possibly merge stuff from your overlay)?
>>>
>>> Regards,
>>> Petteri
>>>
>>>
>>
>> Simply put, the council's purpose is not to say "oh we have to stop
>> development and have a 4 week debate about everything minor". The
>> council's purpose is to help decide between different technical
>> solutions and encourage people to move forward on one unified path.
>> The council's purpose is not to HINDER development as your responses
>> clearly suggest you would like to hinder eclass development but
>> instead to promote positive development.
>
> There seems to be some misunderstanding going on as we (Gentoo) haven't
> approved (in prior councils terms or in the current one which hopes to
> have its first meeting in the coming week or the following) any rules
> about eclass changes having to be discussed or approved by the council.
>
>> Someone along the years the council lost its way and has felt that it
>> needs to stick its fingers into places that it really doesn't belong.
>> Its really become like the upper management at a large company that
>> slows its developers down, instead of helping make them more
>> efficient.
>
> About the issue in discussion, Petteri was recalling that contrary to
> what anyone new to Gentoo might conclude from the current discussion,
> the issue of eclass deprecation has been subject to at least 2 separate
> discussions in the past 2 or 3 years and that in the last round there
> was a proposal for setting minimal deprecation time frames.
>
> - --
> Regards,
>
> Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
> Gentoo- forums / Userrel / Devrel / KDE / Elections

Jorge,

I remember very clearly as you and I were both council members at the
time. My point is that this discussion does not need to even happen
and the council shouldn't even remotely be involved here.

Let developers develop.

--=20
Doug Goldstein