From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KIopF-0007n1-06 for garchives@archives.gentoo.org; Tue, 15 Jul 2008 18:00:33 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D5BB2E072A; Tue, 15 Jul 2008 18:00:29 +0000 (UTC) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by pigeon.gentoo.org (Postfix) with ESMTP id B442BE0712 for ; Tue, 15 Jul 2008 18:00:29 +0000 (UTC) Received: from gw.thefreemanclan.net ([71.242.208.55]) by vms173001.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K42007MZ79PQCG5@vms173001.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Tue, 15 Jul 2008 12:58:38 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw.thefreemanclan.net (Postfix) with ESMTP id 4DCCE1240CD for ; Tue, 15 Jul 2008 13:58:36 -0400 (EDT) Date: Tue, 15 Jul 2008 13:58:36 -0400 From: Richard Freeman Subject: Re: [gentoo-dev] Council meeting summary for 10 July 2008 In-reply-to: <487CCD6A.4030804@gentoo.org> To: gentoo-dev@lists.gentoo.org Message-id: <487CE54C.7040204@gentoo.org> 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 Content-type: text/plain; charset=UTF-8; format=flowed References: <20080713071118.GC1891@comet> <20080713235255.0e2b7f8e@googlemail.com> <20080714002117.731f1408@googlemail.com> <487CC909.6040109@gentoo.org> <20080715171152.4ffb64b9@snowcone> <487CCD6A.4030804@gentoo.org> User-Agent: Thunderbird 2.0.0.14 (X11/20080618) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: e9740053-08f8-4122-a77a-63b58fd58358 X-Archives-Hash: 55646a57740f95ad06978e1425721026 Petteri R=C3=A4ty wrote: > Ciaran McCreesh kirjoitti: >> So you're saying the GLEP's of no use until Portage supports them, but >> Portage can't support them until you say yes to the GLEP... >> >=20 > I am saying that it makes sense to approve both at the same time or hav= e=20 > other official package managers approved before accepting the GLEP. >=20 I'm not sure that implementation of new features in portage or official=20 status for other package managers needs to be a condition for acceptance=20 of this GLEP. The council's main concern was that there wasn't a=20 clearly defined immediate need for the GLEP so it was sensible to defer=20 it. That isn't an unreasonable suggestion. Would it be more constructive to create a list of new=20 features/capabilities that depend on this GLEP. For each I'd define: 1. The feature/unmet need. 2. Why it can't be done or can only be done poorly without the new GLEP. 3. When we're likely to see the feature become available assuming the=20 GLEP were approved. 4. What package managers are likely to implement it. (Ie their=20 maintainers endorse the need. It sounds like this list might already have some items on it - so why=20 not document them? If the council wants to avoid approving the GLSA for a merely=20 theoretical need they might offer to endorse the idea but delay it=20 pending the implementation of one or more of the new features in one,=20 two, or all three major package managers, or pending support by portage.=20 That would give developers some assurance that they wouldn't waste=20 time going down a road only to be shot down later. It is good for the well-being of Gentoo that the council be relatively=20 conservative with regard to potentially-disruptive decisions. They=20 simply want to see that the benefits outweigh the costs. So, just show=20 them the benefits. At some point the case for going forward outweighs=20 the reluctance to do so. --=20 gentoo-dev@lists.gentoo.org mailing list