From nobody Mon Nov 28 07:20:49 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 4NLH260dmNz4jMmP for ; Mon, 28 Nov 2022 07:21:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 4NLH255q7Kz4Ryr for ; Mon, 28 Nov 2022 07:21:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x636.google.com with SMTP id fy37so23457571ejc.11 for ; Sun, 27 Nov 2022 23:21:01 -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=B9VaEXJWTE70GJIa9SxM+o1tELXfxgJ4Jrf7H/iFyR0=; b=4xxZ626uD6/eHKFisITZMcw7Pl5DF/Bt1RYmjLRpPvqYqH55lIpwkykt9jUqUwb8zC 2LHh3iE5t0Y8bMcgK8dElZ5Fn5bLOWRjm6B+7+czXVrW25VuX1X1G12/y1YxCuUgu4ay 2/U+4+Ytx6wvoQipP3LDuIZ6BQSJtaR2//37u07Gmi7FlF5L3ktjPwK3KLxwoRDYBDLw /fDeZVED/3z9LTns9PzODZnOVpFPs7akBJBk4Uf9jrGFMEiR5uM+uFN4Duurt5zKtHsk O1lroc3FIT/iPAg8tOT7d0qeEad41CgjFVpdaNuZoOe8fvAV2BsEBAaJnqOd0B4aYT7d kUPA== 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=B9VaEXJWTE70GJIa9SxM+o1tELXfxgJ4Jrf7H/iFyR0=; b=E0bo1sfFzkoO/i9IcVgqZpQDj45YSPsLwUEytUyA80R8mzdvsH7Q/ZEyHXw4TpoN0g /fXClT0ZulhTvp1BoVp1uSdIa0XlZ5FSiMlpEnAg2/x8xG53+ABTkFhUU9Uy4nVEmBVZ GpmIBiBwpoJlqag3TC6j0Hvp3UPYrN6Mqux33DbWznzaaAvgR35qta77mWuFANxTH+wl qUEIS3FkFgSJTqKfD3L+kaDnE/hK04xz4qtm+ql1ixh6bPsyPnlz/qwhWAeV1cbZxyNd 653Ln2XpgWJ4PkdenMV80LZ00wlU9ZPhw/8teUEmdHZp+y9R+KxLcnRn2cqjAOTcnC2A DBLg== X-Gm-Message-State: ANoB5pkjR6K8BXBUv1IiEiiQb5Qff1nj4tjne6sTJOKBPspLbYuvbJjp Rdqeres49o5S5fZN+FJelrp5rzVFaT6ufaXt/bc2qaUxpiY= X-Google-Smtp-Source: AA0mqf7mSg4JdN9/4GpsCpnMmRJ8OhtbN3F1wS6hODmXJNIP7SoNXvZ3av5yGFrPORz7iTYyJ9Y7okI1nW+qaxNgREw= X-Received: by 2002:a17:907:206f:b0:7bb:cc6b:86d6 with SMTP id qp15-20020a170907206f00b007bbcc6b86d6mr15046560ejb.252.1669620060273; Sun, 27 Nov 2022 23:21:00 -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> <20221128073445.Horde.UA46E1-_SRAS-yFXkM8r5q7@webmail.leidinger.net> In-Reply-To: <20221128073445.Horde.UA46E1-_SRAS-yFXkM8r5q7@webmail.leidinger.net> From: Warner Losh Date: Mon, 28 Nov 2022 00:20:49 -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="0000000000009a4f5705ee82b6c2" X-Rspamd-Queue-Id: 4NLH255q7Kz4Ryr 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 --0000000000009a4f5705ee82b6c2 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 27, 2022 at 11:34 PM Alexander Leidinger wrote: > Quoting Warner Losh (from Sun, 27 Nov 2022 20:12:08 > -0700): > > > > On Sun, Nov 27, 2022 at 7:17 PM Warner Losh wrote: > >> >> >> 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 >> > > I can't do math.... More than 4 years... > > >> 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... >> > > 13.x was branched about 6.5 years ago. When 14 is branched, it will be > 7 years and we'll removing the to the 12 branch point which will be > four and half years. This seems like a good range to oscillate between. > > > If I understand it correctly, you want to target a policy of: > Just before the branch of stable/N we remove old entries from UPDATING and > keep the data of N-2 branches = deleting the data of N-3. > > stable/14 -> keep 13+12 and delete 11. > > Basically we both are aligned and think N-2 is on the edge. I don't mind > to live with this edge... > > Do we want to document that somewhere? RE-tasklist? Inside UPDATING (top > or bottom)? > > What about removing the entries of 10? Now or with next branch? I would > vote to do it now, what's done is done. > I think we should remove entries before the 11 branch now. I'll create a review with that. Warner --0000000000009a4f5705ee82b6c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 27, 2022 at 11:34 PM Alex= ander Leidinger <netchild@freebs= d.org> wrote:

Quoting Warner Losh <imp@bsdimp.com> (from Sun, 27 Nov 2022 20:12:08 -0700):

=C2=A0

On Sun, Nov 27, 2022 at 7:17 PM Warne= r Losh <imp@bsdimp.c= om> wrote:
=C2=A0

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?

=C2=A0
Yes. It's about one release too old, maybe two. More on one or two= in a bit.
=C2=A0

I don't get the "more than just src updates" part. If we d= on't talk=C2=A0
about the source code, isn't src/UPATING not the wrong place to store= =C2=A0
it?

=C2=A0
More than just 'make buildworld updating' or ''updatin= g a system from src'
is what 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 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<= br> 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.

=C2=A0
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.<= /div>
=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

=C2=A0
OK. Traditionally we've lagged a major release or two from what= 9;s
officially supported by the project. Right now the 10.x stuff is defin= itely
too old. The 11.x stuff is borderline (but likely relevant), the 12.x = stuff
is still quite relevant.
=C2=A0
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.
=C2=A0
Most of the folks that have source products with lots of changes have<= /div>
updated to at least 12 as far as I've been able to tell. But many = haven't
jumped to 13 or current yet.
=C2=A0
There are many people still updating their VMs from 11. Traditionally,= they
wait until after 11.x goes unsupported before they update. It's on= ly 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 conferen= ces that
people often put it off for up to 18 months)... 10.x has been unsuppor= ted
for more than 3 years, so historically everybody has moved on. So the<= /div>
=C2=A0
I can't do math.... More than 4 years...
=C2=A0
10.x entries are definitely stale... The 11 entries are on the edge...= =C2=A0 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&= #39;ve
been not so great about this. Better at some times, worse at others...= .
=C2=A0
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 st= ill-supported
releases. We've traditionally weighted towards retention because t= he
cost of retention has been super low.
=C2=A0
This suggests we delete up to the 11 branch point now, and to the 12
branch point when 14 branches in 6 months or=C2=A0so...
=C2=A0
13.x was branched about 6.5 years ago. When 14 is branched, it will be=
7 years and we'll removing the to the 12 branch point which will b= e
four and half years. This seems like a good range to oscillate between= .


If I understand it correctly, you want to target a policy of:
Just before the branch of stable/N we remove old entries from UPDATING and = keep the data of N-2 branches =3D deleting the data of N-3.

stable/14 -> keep 13+12 and delete 11.

Basically we both are aligned and think N-2 is on the edge. I don't min= d to live with this edge...

Do we want to document that somewhere? RE-tasklist? Inside UPDATING (top or= bottom)?

What about removing the entries of 10? Now or with next branch? I would vot= e to do it now, what's done is done.


I think we should remove entries before the 11 branch now. I'll= create a review with that.

Warner
--0000000000009a4f5705ee82b6c2--