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 1Lc02B-0000S8-Uh for garchives@archives.gentoo.org; Tue, 24 Feb 2009 16:21:28 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E7D2BE03F3; Tue, 24 Feb 2009 16:21:26 +0000 (UTC) Received: from mail-gx0-f175.google.com (mail-gx0-f175.google.com [209.85.217.175]) by pigeon.gentoo.org (Postfix) with ESMTP id C9BACE03F3 for ; Tue, 24 Feb 2009 16:21:26 +0000 (UTC) Received: by gxk23 with SMTP id 23so7601761gxk.10 for ; Tue, 24 Feb 2009 08:21:26 -0800 (PST) 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 Sender: antarus@scriptkitty.com Received: by 10.142.156.2 with SMTP id d2mr2608991wfe.64.1235492486017; Tue, 24 Feb 2009 08:21:26 -0800 (PST) In-Reply-To: <49A41D3F.4010706@gentoo.org> References: <1234257125.18160.2016.camel@localhost> <49A1E1CB.1000806@gentoo.org> <20090222234800.29d64b8d@snowcone> <49A206A7.3050604@gentoo.org> <1235378286.31617.6.camel@neuromancer.neuronics-tp.ch> <49A26B84.7040006@gentoo.org> <1235383347.12908.0.camel@neuromancer.neuronics-tp.ch> <49A2B276.1000109@gentoo.org> <49A41D3F.4010706@gentoo.org> Date: Tue, 24 Feb 2009 08:21:25 -0800 X-Google-Sender-Auth: ce891b5ca115e5c6 Message-ID: Subject: Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) From: Alec Warner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 09964d26-cac4-43e0-8cf3-f43c7ff5a968 X-Archives-Hash: 688f7e08d1d0ee7a43603f707b7911d3 Somewhat ironically, had everyone been less stubborn last year when discussing this topic we could have embedded the EAPI in line X of the ebuild in 2008 and be using it now; instead of still discussing it. I don't expect new novel ideas out of this thread. I expect the council to defer it again because the arguments are the same as last time and last time they were not convincing enough. I would prefer if the council went one way or the other so that when we are arguing about this in 2010 we can at least say "hey we have support in $PACKAGE_MANAGERs for EAPI on line X since May 2009 so in 3 months we can just switch. We don't have to make the switch; I'm just saying we should add support to hedge our bets. Thoughts? -A