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 983C913933E for ; Mon, 12 Jul 2021 15:01:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4D832E0D66; Mon, 12 Jul 2021 15:01:06 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 CB5AAE0CF9 for ; Mon, 12 Jul 2021 15:01:05 +0000 (UTC) Date: Mon, 12 Jul 2021 11:01:02 -0400 From: Aaron Bauman To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow Message-ID: References: <2602c61e-7917-2bc3-5d04-e3a170fce710@gentoo.org> <4a32bb48c646e7efbef0305f65516bc2cddb442a.camel@gentoo.org> 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 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="II65OVD0Ao9w+Jkg" Content-Disposition: inline In-Reply-To: <4a32bb48c646e7efbef0305f65516bc2cddb442a.camel@gentoo.org> X-Archives-Salt: 6da283c2-fcbf-456b-8f63-b233b4e12311 X-Archives-Hash: 0bdf9413d51fed10f4238dcd3f4f8465 --II65OVD0Ao9w+Jkg Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 12, 2021 at 04:59:06PM +0200, Micha=C5=82 G=C3=B3rny wrote: > On Mon, 2021-07-12 at 09:33 -0400, Aaron Bauman wrote: > > On Mon, Jul 12, 2021 at 11:38:18AM +0100, Marek Szuba wrote: > > > On 2021-07-11 21:54, Micha=C5=82 G=C3=B3rny wrote: > > >=20 > > > > My gut feeling is that having this distinction is useful. However,= it > > > > has been pointed out that we've probably never really had to use it > > > > (i.e. use the "banned" argument to stop someone from using old EAPI) > > > > and that the switch from "deprecated" to "banned" state did not rea= lly > > > > affect porting away from old EAPI. > > >=20 > > > For the benefit of those not interested in sifting through the logs of > > > Council meetings, here is a quick reiteration of my take on this: > > >=20 > > > 1. Maybe it's my professional bend speaking but it feels to me like we > > > really should establish a clear, GLEP-documented EAPI life cycle with > > > well-defined meaning of individual stages. I will work on preparing a > > > suitable proposal; > > >=20 > > > 2. Until the above has introduced a (hopefully) better system, I am a= ll for > > > removing step 2 because it makes the procedure less bureaucratic. > > >=20 > > >=20 > > > On 2021-07-12 02:11, Aaron Bauman wrote: > > >=20 > > > > Just officially ban it, send out a message, and use the best judgem= ent > > > > when enforcing it (should it even need to be enforced). > > >=20 > > > And the point of establishing a policy doomed from start to be enforc= ed > > > weakly or not at all is? Other than making the Council look like we c= are > > > more about theatrics than actual governance, that is. > > >=20 > > > --=20 > > > Marecki > > >=20 > >=20 > > It is not theatrics. It is a policy that was effective in the past and > > is used in lieu of a technical measure. Albeit, it is unlikely to be > > enforced because most people abide by the deprecation warnings. > >=20 >=20 > That's the whole point. Do we need a two-step deprecation/ban if 'most' > people abide by deprecation warnings? >=20 > I'm wondering if the two-step deprecation/ban isn't a symptom of a wider > problem. After all, we want people to stop using old EAPIs after > they're deprecated, not after they're explicitly forbidden to use them. >=20 > Maybe the whole point is that we should stop trying to draw explicit > lines everywhere and instead assume -- per common sense -- that > deprecating is enough for people to eventually stop using them. >=20 As said, in lieu of that we have a fail safe. --II65OVD0Ao9w+Jkg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEmv7M5qd5RX+UB+cwV6vTrTwY1fAFAmDsWSsACgkQV6vTrTwY 1fDVlwf8DvuAH7aH5UhzjiD4HM5lzwCrocgt02+OtlAkImqUQmetpLOI5iFj1ciC LWQXL5uUoX24Lf/4e/86W3axz/59G65PqaGFieGPcVhVJIqZ7lwFFbkccXYhPtYB WQVlbNFiIMSlTO9eDhfXxTw5p010TPDMhTkv5GPmKvJsEK8eYQqYWNo4HF9OcEuK uLJKps/ABXsTnE0ULYe+rS9+MfSI/E6bthH3oK22X3FSXV1veUXdhKW3l+RpN4Vm WSo6FM0vEZQyGz27bP6yd8r7/Y6FXsvcImA7OIyPGfrM8LlcrAEYmEMOK1BzDo2Q tzqF5yCr+Q4P+aGjqEJI7oYhIBYmRw== =RRJF -----END PGP SIGNATURE----- --II65OVD0Ao9w+Jkg--