From nobody Mon Nov 28 02:17:21 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NL8Hw5w4yz4hb5q for ; Mon, 28 Nov 2022 02:17:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NL8Hw3dk2z41D9 for ; Mon, 28 Nov 2022 02:17:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x633.google.com with SMTP id n20so22560571ejh.0 for ; Sun, 27 Nov 2022 18:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=phJ4S/bVHDJK0F6NyXUceb+mK2YrLtITbJF2GVmx+Qg=; b=33QtTxUYh9LzIz9w+FQnE46qrjwxqXcNOJLFhBYCaoB1bzoleIZkiXoAOSh/gw0BCN fHztH1aCZzneMYlV8P3sjBQ4ABaYTvUz2byd/E32fgmmQ/jPDRLHPzItmre1wiEpfDQ6 D5UjxSWXgWCYS0840zg3r0xaF6k819wHDrxz0xiUIhxmtbZbNRbpQ03k1AOzu+U/Y+Kd 0GKisIVZT1FJZq8mFgGh+5McTkRSro+fMpfI7UAscyO38/kdzU8Y798kviOgmoieOEVD 0OlHfN3g2v7u5MGeDPqH3zGvG4gkY9LHhRXiYotf15MmXY4SeV9UfLr/Ziaars+U2FPx VKeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=phJ4S/bVHDJK0F6NyXUceb+mK2YrLtITbJF2GVmx+Qg=; b=LQqXHIoaEjM4+SK6Dn+1mbDelUFctcLyeRFwvmFbJOW/0TPK8TvLM5INT5XisegEPN 83YrInw1kV7EfZgR/uD4g5En3lIE7ffa76MKtXICgKH8ZntCxJ/KdNXuHRiL3D3dLMNd vZsRb8KyxGRyD3uAVQqLp+NmDXSx4mdEhIz9yTsZGS7VFdrqgpl/FOXQaUeZjT7UKPqB qeB9ZHCt3Scs3SndL2fMspLZVARhgOkJiE5wGKWZo/OCaC324GXPKgmIxwpSeW9Qp5O/ 0NZR1Kjxhf7CfjUphjw6gy+UWh2qKIwuPvqJ3bdEXN6XsrkKKgIbhpc8/KkbxD1ZYEYG roxg== X-Gm-Message-State: ANoB5pnepcZnrZKzLsRWVfaq3H/8rbYfhuNS7T9ry6qs4xkoXEZZAWoL Sy6jTmbpoZjwasyJDn446IdV+74Azp5fhk2Zv0FNpH1WIIU= X-Google-Smtp-Source: AA0mqf7h6SFZYyjOmBkTcnAASMxAP6vENaF5+vIxlmkCWL6bhhDO9f5saw6/Eh2VbiyqFbXuoO8kPzKNCyxvPxIJnEg= X-Received: by 2002:a17:906:f84d:b0:7b9:631b:7dfb with SMTP id ks13-20020a170906f84d00b007b9631b7dfbmr22458029ejb.32.1669601848487; Sun, 27 Nov 2022 18:17:28 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <202211250923.2AP9NakT073087@gitrepo.freebsd.org> <20221127223531.Horde.3qMyxtWhJEa3tXdg500ge5g@webmail.leidinger.net> In-Reply-To: <20221127223531.Horde.3qMyxtWhJEa3tXdg500ge5g@webmail.leidinger.net> From: Warner Losh Date: Sun, 27 Nov 2022 19:17:21 -0700 Message-ID: Subject: Re: How much to remove from UPDATING (was: Re: git: ff0c7816db69 - main - Remove UPDATING entries from old branches.) To: Alexander Leidinger Cc: freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="00000000000018842805ee7e79c4" X-Rspamd-Queue-Id: 4NL8Hw3dk2z41D9 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000018842805ee7e79c4 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 27, 2022 at 2:35 PM Alexander Leidinger wrote: > Quoting Warner Losh (from Fri, 25 Nov 2022 09:41:28 > -0700): > > > Please revert this. We keep older updating entries on purpose. You purged > > way too much. Let's chat about how much to remove in arch@. They are for > > more than just source updates, so your reasoning is wrong. They are also > > there for users updating their products which can have a larger leap in > > time. We've traditionally kept closer to 5-10 years here for that reason. > > Reverted. > > UPDATING as far back as stable/10 (= 4 major updates) is a little bit > excessive (more than 9 years of development work so far), isn't it? > Yes. It's about one release too old, maybe two. More on one or two in a bit. > I don't get the "more than just src updates" part. If we don't talk > about the source code, isn't src/UPATING not the wrong place to store > it? > More than just 'make buildworld updating' or ''updating a system from src' is what I mean. > In terms of updating products, I understand that updating them every 2 > years may be a little bit expensive/excessive for some vendors, but > taking every UPDATING from every stable branch in-between doesn't look > too much time consuming to me. And compared to the huge amount of > changes between N-2 and N... taking UPDATING from all stable branches > in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish, > nearly 10 years is ... ugh ... a life-time or two in the computer > world. If we look e.g. at the PlayStation (yes, just one of the > products which has FreeBSD inside, but personally I consider it one of > the more stable ones than some network products which have a shorter > shelf-time than the PS-line from an OS-version-tracking point of > view), there are around 6 years in-between models, and they surely > haven't started developing a month before the release date. > So, let's look at what it's used for to see how much we need. If you look at it that way, you'll see that we're not crazy lagging. > So where do we draw the line for UPDATING, 2 major versions (~4 > years), 3 major versions (~6 years)? ~10 years (~5 major versions) > looks overly excessive to me. That's not something you want to try to > catch up, that's rather a new development than a catch-up OK. Traditionally we've lagged a major release or two from what's officially supported by the project. Right now the 10.x stuff is definitely too old. The 11.x stuff is borderline (but likely relevant), the 12.x stuff is still quite relevant. We need to look at who is updating. Many people have only recently updated from 11. Almost everybody has updated from 10 by now. Lots of people are using 12 and it's still supported. Most of the folks that have source products with lots of changes have updated to at least 12 as far as I've been able to tell. But many haven't jumped to 13 or current yet. There are many people still updating their VMs from 11. Traditionally, they wait until after 11.x goes unsupported before they update. It's only been unsupported for just over 1 year. In the past, this is where upgrading is hitting full speed (I've received feedback in the past at conferences that people often put it off for up to 18 months)... 10.x has been unsupported for more than 3 years, so historically everybody has moved on. So the 10.x entries are definitely stale... The 11 entries are on the edge... I'd normally have removed the 10.x entries when 13 was branched, but I was asleep at the wheel this time.... Though looking at the logs, I've been not so great about this. Better at some times, worse at others.... So in my opinion, 10.x entries should have already been gone. 11.x entries are likely useful enough to keep, but they are waning fast. 12.x entries are likely being used all the time by people upgrading from still-supported releases. We've traditionally weighted towards retention because the cost of retention has been super low. This suggests we delete up to the 11 branch point now, and to the 12 branch point when 14 branches in 6 months or so... Warner --00000000000018842805ee7e79c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 27, 2022 at 2:35 PM Alexa= nder Leidinger <netchild@freebsd.org> wrote:
Quoting Warner Losh <imp@bsdimp.com> (from Fri, 25 Nov 2022 09:41:= 28 -0700):

> Please revert this. We keep older updating entries on purpose. You pur= ged
> way too much. Let's chat about how much to remove in arch@. They a= re for
> more than just source updates, so your reasoning is wrong. They are al= so
> there for users updating their products which can have a larger leap i= n
> time. We've traditionally kept closer to 5-10 years here for that = reason.

Reverted.

UPDATING as far back as stable/10 (=3D 4 major updates) is a little bit=C2= =A0
excessive (more than 9 years of development work so far), isn't it?
=

Yes. It's about one release too old, m= aybe two. More on one or two in a bit.
=C2=A0
I don't get the "more than just src updates" part. If we don&= #39;t talk=C2=A0
about the source code, isn't src/UPATING not the wrong place to store= =C2=A0
it?

More than just 'make buildworld= updating' or ''updating a system from src'
is wh= at I mean.
=C2=A0
In terms of updating products, I understand that updating them every 2=C2= =A0
years may be a little bit expensive/excessive for some vendors, but=C2=A0 <= br> taking every UPDATING from every stable branch in-between doesn't look= =C2=A0
too much time consuming to me. And compared to the huge amount of=C2=A0 changes between N-2 and N... taking UPDATING from all stable branches=C2=A0=
in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish,=C2=A0
nearly 10 years is ... ugh ... a life-time or two in the computer=C2=A0 world. If we look e.g. at the PlayStation (yes, just one of the=C2=A0
products which has FreeBSD inside, but personally I consider it one of=C2= =A0
the more stable ones than some network products which have a shorter=C2=A0 =
shelf-time than the PS-line from an OS-version-tracking point of=C2=A0
view), there are around 6 years in-between models, and they surely=C2=A0 haven't started developing a month before the release date.

So, let's look at what it's used for to se= e how much we need. If you
look at it that way, you'll see th= at we're not crazy lagging.
=C2=A0
So where do we draw the line for UPDATING, 2 major versions (~4=C2=A0
years), 3 major versions (~6 years)? ~10 years (~5 major versions)=C2=A0 looks overly excessive to me. That's not something you want to try to= =C2=A0
catch up, that's rather a new development than a catch-up
<= div>
OK. Traditionally we've lagged a major release or tw= o from what's
officially supported by the project. Right now = the 10.x stuff is definitely
too old. The 11.x stuff is borderlin= e (but likely relevant), the 12.x stuff
is still quite relevant.<= br>

We need to look at who is updating. Many peopl= e have only recently
updated from 11. Almost everybody has update= d from 10 by now. Lots
of people are using 12 and it's still = supported.

Most of the folks that have source prod= ucts with lots of changes have
updated to at least 12 as far as I= 've been able to tell. But many haven't
jumped to 13 or c= urrent yet.

There are many people still updating t= heir VMs from 11. Traditionally, they
wait until after 11.x goes = unsupported before they update. It's only been
unsupported fo= r just over 1 year. In the past, this is where upgrading is
hitti= ng full speed (I've received feedback in the past at conferences that
people often put it off for up to 18 months)... 10.x has been unsu= pported
for more than 3 years, so historically everybody has move= d on. So the
10.x entries are definitely stale... The 11 entries = are on the edge...=C2=A0 I'd
normally have removed the 10.x e= ntries when 13 was branched, but
I was asleep at the wheel this t= ime.... Though looking at the logs, I've
been not so great ab= out this. Better at some times, worse at others....

So in my opinion, 10.x entries should have already been gone. 11.x
<= div>entries are likely useful enough to keep, but they are waning fast. 12.= x
entries are likely being used all the time by people upgrading = from still-supported
releases. We've traditionally weighted t= owards retention because the
cost of retention has been super low= .

This suggests we delete up to the 11 branch poin= t now, and to the 12
branch point when 14 branches in 6 months or= =C2=A0so...

Warner

<= /div> --00000000000018842805ee7e79c4--