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 95D07138CE3 for ; Mon, 10 Feb 2014 13:23:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 954A8E09A4; Mon, 10 Feb 2014 13:22:58 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 93564E086D for ; Mon, 10 Feb 2014 13:22:57 +0000 (UTC) Received: from [192.168.3.7] (cpe-74-77-145-97.buffalo.res.rr.com [74.77.145.97]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: blueness) by smtp.gentoo.org (Postfix) with ESMTPSA id B884F33F8A2 for ; Mon, 10 Feb 2014 13:22:56 +0000 (UTC) Message-ID: <52F8D2E7.3030901@gentoo.org> Date: Mon, 10 Feb 2014 08:23:51 -0500 From: "Anthony G. Basile" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Tightening EAPI rules References: <52F8C97D.4030403@gentoo.org> In-Reply-To: <52F8C97D.4030403@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 0a2ef524-f764-4dd8-bbed-e21b92ec94f3 X-Archives-Hash: a9d5409d4f223b29ff03f8357f1bb555 On 02/10/2014 07:43 AM, Patrick Lauer wrote: > EAPI 4 becomes deprecated when/if there's a new EAPI allowed in-tree > (EAPI 6, most likely) I am concerned about making this a "rule". While I think its okay for the 4/5/6 move, I'm not sure if it will always be a good idea. 1) "Deprecating" an EAPI can mean breakage --- see my next point. 2) To tie the deprecation of the older EAPI to the introduction of a newer one can delay the introduction of the newer one and possibly needed features. You will connect the question of "are we ready to deprecate X" with the question "we need to introduce Y for needed features a, b and c." The statement "Deprecating an EAPI can mean breakage" depends on what we mean by "deprecating." I'm assuming here we mean something like repoman won't allow commits at EAPI=1,2,3 but that ebuilds in the tree at those EAPI's will continue working. Eg. dosed which was deprecated in the EAPI 3 to 4 jump. I think we should look at the question of deprecating EAPI's on and ad hoc basis with discussion on the list and a vote in the council. --Tony > > > Please no bikeshedding, It should be red. > -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA