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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 81081158094 for ; Tue, 2 Aug 2022 04:48:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1251AE0FC7; Tue, 2 Aug 2022 04:48:48 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 48A56E0F56 for ; Tue, 2 Aug 2022 04:48:47 +0000 (UTC) From: Sam James Content-Type: multipart/signed; boundary="Apple-Mail=_1FBFD2C3-EB55-4907-B879-B7131910FCC4"; protocol="application/pgp-signature"; micalg=pgp-sha512 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [gentoo-dev] GLEP 83 [v3]: EAPI deprecation Date: Tue, 2 Aug 2022 05:48:43 +0100 References: To: gentoo-dev@lists.gentoo.org In-Reply-To: Message-Id: <3F397D5A-6CF2-4EE7-88F2-3FCF792FFF8A@gentoo.org> X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Archives-Salt: 9a73995a-9a85-4b34-8e67-cdd5e0126af6 X-Archives-Hash: a1156a7e325c66e4b1f9bc92a66ac1e1 --Apple-Mail=_1FBFD2C3-EB55-4907-B879-B7131910FCC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 1 Aug 2022, at 22:24, Duncan <1i5t5.duncan@cox.net> wrote: >=20 > Ulrich Mueller posted on Sun, 31 Jul 2022 23:26:13 +0200 as excerpted: >=20 >> Update v3 >=20 > One language thing and two possible clarifications. >=20 >> --- >> GLEP: 83 Title: EAPI deprecation >> Author: Ulrich M=C3=BCller >> Type: Informational Status: Draft >> Version: 1 >> Created: 2022-06-30 >> Last-Modified: 2022-07-31 >> Post-History: 2022-07-11, 2022-07-31 >> Content-Type: text/x-rst >> --- >=20 >> Specification =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> A *deprecated EAPI* is no longer required for the upgrade path of = users' >> systems. Its use is discouraged, and tools like pkgcheck will warn >> about this [#COUNCIL-20130409]_. >>=20 >> A *banned EAPI* must no longer be used, neither for new ebuilds, nor = for >> updating of existing ebuilds [#COUNCIL-20140311]_. >>=20 >> The Gentoo Council will deprecate an EAPI when >>=20 >> * two newer Council-approved EAPIs are supported by the stable = version >> of Portage, and >> * one of them has been supported for 24 months. >>=20 >> The Gentoo Council will ban a deprecated EAPI when >>=20 >> * 24 months have passed since its deprecation, and * it is used by = fewer >> than 5 % of ebuilds in the Gentoo repository. >=20 > The first possible clarification fits here (I think). Something like: >=20 > This GLEP is intended as a policy reference guide for EAPI minimum = effective > times. Despite the statistical qualifications listed here no EAPI > will be deprecated or banned without specific Gentoo Council action. >=20 > (While this is implied by the "Gentoo Council will..." wording, making = it > explicit could prevent later confusion/controversy.) If anything, this might make things more confusing, given it implies the Council can deviate if it wants. >=20 >> EAPIs used in profiles are outside the scope of this GLEP. >>=20 >>=20 >> Rationale =3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Timing of EAPI deprecation is a trade-off between different factors. >> On the one hand, the total number of EAPIs in active use should be >> limited; this will prevent the learning curve for new developers and >> contributors from becoming too steep and will help to reduce code >> complexity, e.g. in eclasses. >=20 > The language point: >=20 > Am I the only one for whom the omission of "from" makes the sentence = read > smoother? (Maybe it's a regional English thing?) >=20 > ; this will prevent the learning curve [...] from becoming too = steep... >=20 > ; this will prevent the learning curve [...] becoming too steep... >=20 It reads slightly smoother without "from" but I didn't notice it when reading myself. I guess we can drop it. >> On the other hand, an upgrade path to a stable system is guaranteed = for >> one year, plus limited support for systems that are outdated more = than a >> year [#COUNCIL-20091109]_. Therefore, previous EAPIs are still = required >> during that time. A period of 24 months before deprecation has been >> chosen, which is more than the required minimum and will allow = projects >> to support a longer upgrade path. >>=20 >> Requiring two newer EAPIs before deprecation will allow ebuilds that = are >> otherwise seldom updated to be bumped to the next but one EAPI >> immediately. >=20 >> A delay of 24 months between deprecation and ban will give ebuild >> authors enough time to update. This is especially relevant for = overlays >> and downstream distributions. An additional requirement for banning = an >> EAPI is that fewer than 5 % of ebuilds are using the EAPI in = question. >> This requirement is defined to help keep the number of ebuild updates >> (and bug reports requesting them) managable, as a banned EAPI is >> sufficient reason for updating an ebuild. >=20 > The second possible clarification seems to fit about here, but may = require > a bit of adjustment to the text above it. >=20 > The two 24-month times are effectively additive, yielding a total 48 = months > minimum between addition of an EAPI and banning of the previous one. = Given > past EAPI history of at minimum a year between EAPI introductions that = should > yield a minimum three years of active EAPI life before deprecation, = one year > minimum as the newest EAPI plus two years before deprecation, plus two = years > of deprecation, for five years total EAPI life before ban. >=20 > (This isn't entirely necessary but makes explicit the answer to one of = my first > questions reading the proposal. YMMV. I debated spec vs rational, = but decided > rational was a better fit.) >=20 > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman >=20 >=20 --Apple-Mail=_1FBFD2C3-EB55-4907-B879-B7131910FCC4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCYuisq18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kHBlAP977Yvr/yKea/yDHgXXBsCHc3PsIHC11lS/owVLTvtYrAEA/yCg0vgbDfna UVdOgNfZRjkHDHoaUyeVNdp9uTCwoAI= =rLxN -----END PGP SIGNATURE----- --Apple-Mail=_1FBFD2C3-EB55-4907-B879-B7131910FCC4--