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 03971138350 for ; Mon, 2 Mar 2020 12:46:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BE00FE08C4; Mon, 2 Mar 2020 12:46:48 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.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 8515EE08C3 for ; Mon, 2 Mar 2020 12:46:48 +0000 (UTC) Received: from pomiot (c142-245.icpnet.pl [85.221.142.245]) (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 9F64534ED5B; Mon, 2 Mar 2020 12:46:45 +0000 (UTC) Message-ID: <057597b3b2b8e8ea2deccca7e3b6f700d2aff820.camel@gentoo.org> Subject: Re: [gentoo-project] Call for agenda items - council meeting 2020-03-08 From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-project@lists.gentoo.org Date: Mon, 02 Mar 2020 13:46:41 +0100 In-Reply-To: References: <20200225195903.99dff9f8fd997e62dafdbc4a@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-zs++YlUIJLLhma9q0uV3" User-Agent: Evolution 3.32.5 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: 455877b3-6c5d-4557-8906-9222c3ef436b X-Archives-Hash: e02eeb6d096a7cc4fe8414e54154fdbf --=-zs++YlUIJLLhma9q0uV3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2020-03-02 at 13:38 +0100, Ulrich Mueller wrote: > > > > > > On Mon, 02 Mar 2020, Micha=C5=82 G=C3=B3rny wrote: > > Following the discussion within the QA team, I'd like to ask the Counci= l > > to clarify whether EAPI 4 ban applies to revision bumps as a result of > > dependency changes? > > I think the key point in banning EAPIs is that the maintainer (or > > generally, someone caring about the package in question) should be > > responsible for the EAPI bump. I don't think anybody should be forced > > to do that when in middle of large batch of changes (read: when I only > > touch the package because it's blocking me). > > In this particular case, I'm thinking of revbumps due to dependency > > changes. Say, if I do a change in a dependency *I* maintain, and have > > to fix a large number of revdeps, I don't think it's fair to expect me > > to EAPI-bump some packages I don't maintain. The main difference is > > that we're talking of dep change + revbump that can be linted via > > pkgcheck/repoman vs. EAPI bump that needs full scale testing. >=20 > EAPIs are being banned after a deprecation period, which typically is > two years. So I guess one can expect packages that run into the ban not > to be very actively maintained. >=20 > Looking at the plots [1] (especially the third plot from the top), > I don't see any change in slope for EAPI 0 in 2016-01 or for EAPI 4 > in 2018-04. So arguably, the "banned" state doesn't give any additional > incentive to update an ebuild, as compared to the "deprecated" state. > After your proposed change, the difference between the two states would > be even more blurred. >=20 > Maybe we should revisit the concept, and ban EAPIs only when their last > ebuild has left the tree, i.e., when the EAPI is added to eapis-banned > in layout.conf? >=20 Not sure if this is practically able but technically I see an advantage from having three distinct states: 1. Deprecation -- tooling warns about them but there are no consequences for adding new ebuilds. 2. Ban I -- tooling errors out, if developers add new ebuilds (as in real new ebuilds), we pursue it. 3. Ban II -- no ebuilds left, CI fatal, immediate revert. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-zs++YlUIJLLhma9q0uV3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAl5dADFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM3 NkE4NDUwOTQwOThEMjhDQzhCMjZDNTYzOUFEQUUyMzI5RTI0MEUACgkQY5ra4jKe JA4j9QgAyxjl3y/NMbbADBob1/uwl/91Lixj/j4Xu68MmwhWANBAfUbW74Hj4zkn /YB0gg9Kw8ilMqFf8RJvV49s5jPFFRrge2WUPGbdVRWYfI027d6Tg7ON3brUg0GG mBwXgXDCMJOSpwWqoVOl607F5zss3y+G7xFGRKHzhmlFFrrTUKFmegL2WxSYgFkI D+eolYoLVKZQivgAjSs6Wl5tsjKLOg7LEBKmMlUj/qyoDReiEx5fFJAvO3ZSgwaF ZRwqQ5BeCFadoxgr5xNqKtp6I2jHqhiNmt0Y655H9/87cxdujzGch8CAVjnZcEYf 2wkCgqBLRq99wACQMBwX+3RPihAqGw== =ts/8 -----END PGP SIGNATURE----- --=-zs++YlUIJLLhma9q0uV3--