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 65C6E138010 for ; Fri, 5 Oct 2012 09:03:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E96EC21C002 for ; Fri, 5 Oct 2012 09:03:08 +0000 (UTC) Received: from a1iwww1.kph.uni-mainz.de (a1iwww1.kph.uni-mainz.de [134.93.134.1]) by pigeon.gentoo.org (Postfix) with ESMTP id 21ED221C001 for ; Fri, 5 Oct 2012 08:46:38 +0000 (UTC) Received: from a1i15.kph.uni-mainz.de (a1i15.kph.uni-mainz.de [134.93.134.92]) by a1iwww1.kph.uni-mainz.de (8.14.4/8.13.4) with ESMTP id q958kbCb025647 for ; Fri, 5 Oct 2012 10:46:37 +0200 Received: from a1i15.kph.uni-mainz.de (localhost [127.0.0.1]) by a1i15.kph.uni-mainz.de (8.14.5/8.14.2) with ESMTP id q958kbXC025407; Fri, 5 Oct 2012 10:46:37 +0200 Received: (from ulm@localhost) by a1i15.kph.uni-mainz.de (8.14.5/8.14.5/Submit) id q958kajq025405; Fri, 5 Oct 2012 10:46:36 +0200 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20590.40556.939437.204618@a1i15.kph.uni-mainz.de> Date: Fri, 5 Oct 2012 10:46:36 +0200 To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012 In-Reply-To: <506E8197.8060504@gentoo.org> References: <20120925092414.GL37574@gentoo.org> <1348601570.3603.4.camel@belkin4> <20121002113020.GZ37574@gentoo.org> <1349284689.2200.50.camel@belkin4> <1349375561.2200.57.camel@belkin4> <20121005062851.GI912@gentoo.org> <506E8197.8060504@gentoo.org> X-Mailer: VM 8.2.0b under 23.4.2 (x86_64-pc-linux-gnu) From: Ulrich Mueller X-Archives-Salt: 1a1cfe1f-0838-4da4-8805-c468c6b9c7c2 X-Archives-Hash: f9cd4ae6d2950dd68352f14ae97ef25b >>>>> On Fri, 05 Oct 2012, Patrick Lauer wrote: > I would suggest adding a repoman warning for adding new ebuilds with > EAPI={1,2,3} now, turn that into an error for EAPI 1 in a short time > (3 months?), then do the same for EAPI 2 a short while later with a > longer timeline (as there are substantially more ebuilds with EAPI 2) I don't see any advantage in deprecating intermediate EAPIs, before we deprecate EAPI 0. What problem are you trying to solve? Ulrich