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 0B2731382C5 for ; Tue, 6 Mar 2018 22:21:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8BB05E09EB; Tue, 6 Mar 2018 22:21:40 +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 3571EE09DC for ; Tue, 6 Mar 2018 22:21:40 +0000 (UTC) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mattst88) by smtp.gentoo.org (Postfix) with ESMTPSA id DCB2D335C0C for ; Tue, 6 Mar 2018 22:21:38 +0000 (UTC) Received: by mail-it0-f52.google.com with SMTP id j7so845663ita.3 for ; Tue, 06 Mar 2018 14:21:38 -0800 (PST) X-Gm-Message-State: AElRT7Gi9fIdWSohN9yCfxRaUR0PxzvoElCmioaSLF75pEPM4GPFJsAb tJbiDWR+FfFOwbETAsvKU/22wJJEqG/Sc3k2b+Q= X-Google-Smtp-Source: AG47ELvV2mc7WuOKSCt+tqe5S3/SKLT2TcgrJjYqUhLJ8JE8FQ5ry4tRPz7A02SicaTWjkpY82exf1gqUgYkrmShZbI= X-Received: by 10.36.50.66 with SMTP id j63mr20698064ita.13.1520374897091; Tue, 06 Mar 2018 14:21:37 -0800 (PST) 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 Received: by 10.2.168.15 with HTTP; Tue, 6 Mar 2018 14:21:16 -0800 (PST) In-Reply-To: <32379196.J1ePdnhnO0@pinacolada> References: <32379196.J1ePdnhnO0@pinacolada> From: Matt Turner Date: Tue, 6 Mar 2018 14:21:16 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [gentoo-dev] Is removing old EAPIs worth the churn? To: gentoo development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: e47184b1-66c9-4a22-9838-e3a736bcd57f X-Archives-Hash: 0ab0f7c83ff39cc3dd263e79edb5edb3 On Tue, Mar 6, 2018 at 1:17 PM, Andreas K. Huettel w= rote: > Am Dienstag, 6. M=C3=A4rz 2018, 02:52:54 CET schrieb Matt Turner: >> EAPI 2 removal bug: https://bugs.gentoo.org/648050 >> >> It seems like tons of churn to update old stable ebuilds to a new >> EAPI, just for its own sake. Take https://bugs.gentoo.org/648154 for >> example. New ebuild added with EAPI 6 bumped from EAPI 2. Otherwise >> functionally identical. Now asking arch teams to retest and >> restabilize. Multiply by 100 or more. > > OK so here's my personal opinion: > > Is it worth the effort? Yes, see below. > Is it a high priority task? No. > > Is it really that much effort? Well, we're even in the case of EAPI=3D2 t= alking > about only 400 ebuilds of 35000 in total. That's roughly 1% of the tree. = And > I'd strongly suspect that even without the EAPI update it would make very= much > sense to check these 400 old ebuilds and test whether they still work as > intended. There are plenty of reported bugs to look at. No need to go searching for more :) > What do we gain? > > * Mainly, less stuff to memorize. I'll be throwing a party on the day whe= n the > last EAPI=3D0 ebuild is gone. (In the retirement home, probably.) This is the argument made by others about the cognitive overhead of remembering all the EAPI differences. If the packages are untouched for ages and don't require maintenance, my claim is that there is no cognitive load to begin with. > * Also, it's not just having a bigger number, but also useful features... > > Why now EAPI=3D2? > > * EAPI=3D3 is nearly gone (27 ebuilds left, scheme & java please get a mo= ve! :) > * EAPI=3D2 is the one with the next-least ebuilds. > > While it would be very nice to remove EAPI=3D0, let's go for easier targe= ts > first; the number of EAPI=3D0 ebuilds will decrease organically in the me= antime. > > [Interestingly, as long as no specific efforts are made, the number of eb= uilds > in all deprecated EAPI decreases roughly equally and exponentially. That = means > the probability of any old ebuild to be removed within a certain time int= erval > is a constant as function of time...] This is a great point in favor of *not* bothering to proactively bump EAPI.