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 ) id 1OXz0o-0000Gh-Cu for garchives@archives.gentoo.org; Sun, 11 Jul 2010 16:04:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3A8B6E0CE2; Sun, 11 Jul 2010 16:04:05 +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 EE3AFE0CA6 for ; Sun, 11 Jul 2010 16:03:39 +0000 (UTC) Received: by vws15 with SMTP id 15so3833884vws.40 for ; Sun, 11 Jul 2010 09:03:39 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.220.49.204 with SMTP id w12mr6328023vcf.103.1278864219352; Sun, 11 Jul 2010 09:03:39 -0700 (PDT) Sender: cardoe@cardoe.com Received: by 10.220.182.77 with HTTP; Sun, 11 Jul 2010 09:03:39 -0700 (PDT) In-Reply-To: <4C39BDCE.3010602@gentoo.org> References: <4C37A114.9070604@gentoo.org> <4C381392.5050505@gentoo.org> <20100710083437.GA6598@hrair> <20100710210258.2005f27c@gentoo.org> <4C39BDCE.3010602@gentoo.org> Date: Sun, 11 Jul 2010 11:03:39 -0500 X-Google-Sender-Auth: 7HL44frK7NDRIEyX8d9OgDJGbiw Message-ID: Subject: Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others From: Doug Goldstein To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 21d9938e-ceab-4bb9-9276-3a023a85d51f X-Archives-Hash: b5ef26756d3fe99069163b60540274a1 On Sun, Jul 11, 2010 at 7:49 AM, Petteri R=C3=A4ty = 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 is > 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 would > 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. 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. --=20 Doug Goldstein