From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C5CFD1382C5 for ; Thu, 29 Mar 2018 13:34:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E78A4E08F7; Thu, 29 Mar 2018 13:34:10 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B4193E0863 for ; Thu, 29 Mar 2018 13:34:10 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id D5FA4335D0B; Thu, 29 Mar 2018 13:34:08 +0000 (UTC) Message-ID: <1522330445.1006.21.camel@gentoo.org> Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2018-04-08 From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-project@lists.gentoo.org Date: Thu, 29 Mar 2018 15:34:05 +0200 In-Reply-To: <23228.52463.901357.194625@a1i15.kph.uni-mainz.de> References: <87muyt9njh.fsf@gentoo.org> <1522318392.1006.16.camel@gentoo.org> <23228.52463.901357.194625@a1i15.kph.uni-mainz.de> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 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-Transfer-Encoding: 8bit X-Archives-Salt: 93d27a7a-8de1-4774-8b9f-b33ea1062df7 X-Archives-Hash: 53f79ecae92fc92b026542aa7e7b1d7f W dniu czw, 29.03.2018 o godzinie 13∶24 +0200, użytkownik Ulrich Mueller napisał: > > > > > > On Thu, 29 Mar 2018, Michał Górny wrote: > > Next item: provided that EAPI 7 is approved, we'd have 4 'live' EAPIs > > in motion [1]. I'd like therefore request the Council to vote on: > > a. banning EAPI 4 for new ebuilds (and EAPI bumps of existing ebuilds). > > It has been deprecated on 2015-10-11. In the past, deprecated EAPIs were > > banned within 11/23 months from deprecation, so we're overdue. > > Fine with me. > > > 2. deprecating EAPI 5. In case of EAPIs 3-4 they were deprecated 4-5 > > years after being added. > > I think a better indicator is the time between support for EAPI n+1 in > stable Portage, and deprecation of EAPI n (see [1]). Using this, I get > 37 months for EAPI 2, 35 months for EAPI 3, and 34 months for EAPI 4 > deprecation. > > > EAPI 6 has been added on 2015-11-13, and even toolchain team already > > uses it, so there's really no reason to use EAPI 5 anymore. > > Stable Portage supports EAPI 6 since 2016-01-17, i.e. since 26 months. > So we would be somewhat on the early side. Not that it's less than the supported upgrade path. > What worries me more is that deprecation of EAPI 5 would apply to > profiles too. However, all profiles are still at EAPI 5 at this point, > and I don't see any value in upgrading them to EAPI 6. That's a fair argument. However: 1. Does deprecation really mean anything in terms of profiles? Even in the context of EAPI bans we explicitly stated that it affects new packages and EAPI bumps. I think deprecating it for ebuilds is still meaningful even if profiles would stay EAPI 5. 2. Do we want to keep profiles EAPI 5 indefinitely? If we consider it a goal to reduce the number of EAPIs in use, I think it would be reasonable to bump profiles to EAPI 6 proactively, even if it doesn't change anything. > > Ulrich > > > [1]:https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification#Council_approval_and_use_in_Gentoo_repository -- Best regards, Michał Górny