From nobody Mon Nov 28 07:38:24 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 4NLHQK67CMz4jPTq for ; Mon, 28 Nov 2022 07:38:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 4NLHQJ6LgLz4TYw for ; Mon, 28 Nov 2022 07:38:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=hBg39haA; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62a) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x62a.google.com with SMTP id td2so9480634ejc.5 for ; Sun, 27 Nov 2022 23:38: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=TOGAppEscx4TjfZqC1eIi/BjiI/LVqPbF6HAvOsy9Lw=; b=hBg39haA7UcczCZ2v/0GTjv3g/L2p44mwqOPLu3C4KG3uolrt9XhHeYoSasiR6aW2j eNgr5nBc89ZiDAeDz7le6+vjVo+2IZDGUQHOh8cRqWU2TlKnVhbaJ2G/lK8GnBivOm7+ nYNeVei0PsLUq4/KLUfmk667fYlrsn7M+m21nVvZnR44DqH8sCKn4b6VY2fvGn9bVTIe R2xksqcxodXoWAhjf9LyQ8wjENIZsr7dtyKBRyEFZ4Ew6JYGBS5tcca/zUXrYdki1Gws 7EZN78p+FwORGOlKRnIEEYUGjR6w+vx1IbGeuLeUoBdbos6WKIvdgtmT8Cy/7i2ZHJXy VRuQ== 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=TOGAppEscx4TjfZqC1eIi/BjiI/LVqPbF6HAvOsy9Lw=; b=LBZuO//1J28ZmCzMcgoHwXOMVJIYjjUoxhaz39U1u/0FtqEZOeOpm+r5h3UbS/2mWS PlT2iGcd+8Mct81ESM5SoKpyPJKOXkEZwlPFW3rcdbxdAaK5oFGeBz1lLEIuGApgQMVx L4A5O4Pdlu6qkaQ5BrKCoqLgYDSkGN072LYLhV+7KoQ2U7+hGZec471hEDpajmbS2Q4e U7hgSa1nvI+ImlviYGH3GT1oB47jUbHSOtkmsNOeXmgdaTCj//ySZfoZ5ZY7mMw64gNe UvWrcOVaFg16R7rbL3DYx8CxzYLCGMM6pEWflcM4E3wFgaoeqpZ41ogb7hcvSSd0IyII +i/w== X-Gm-Message-State: ANoB5plzqkygH3CNNYnC4Aqe/I6AKrhvPtWyaR6Hcuu/SFr7Nhviq4wo kokCicLjn7gqTTSLGibyHiA4xHDVfhdg1x0omBt+kO15DHCnMw== X-Google-Smtp-Source: AA0mqf7HuB2w5zI+Uu1+Cj6e57y0+W1VskbB7edxGka9wyxoBIh620R0W6C05HreUeU6dKIIlBr/HYs/rIvvRuWxQNE= X-Received: by 2002:a17:907:206f:b0:7bb:cc6b:86d6 with SMTP id qp15-20020a170907206f00b007bbcc6b86d6mr15092020ejb.252.1669621111432; Sun, 27 Nov 2022 23:38:31 -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: From: Warner Losh Date: Mon, 28 Nov 2022 00:38:24 -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="00000000000041bc3d05ee82f5b5" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NLHQJ6LgLz4TYw X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --00000000000041bc3d05ee82f5b5 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 28, 2022 at 12:20 AM Warner Losh wrote: > > > 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 < >>> netchild@freebsd.org> 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. > https://reviews.freebsd.org/D37514 has the changes for UPDATING. We likely should document this in the RE-tasklis, with the caveat that the sequence is 'create a new branch, trim UPDATING in -current only' rather than the opposite to the stable/XX branch has the older data. I think I trimmed the right amount. We likely should also have $SOMEBODY review the build / updating / etc instructions at each release so we can keep them up to date as well as technology evolves. Warner --00000000000041bc3d05ee82f5b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 28, 2022 at 12:20 AM Warn= er Losh <imp@bsdimp.com> wrote:=


On Sun, Nov 27, 2022 at 11:34 PM Alexander Leidinger= <netchild@fre= ebsd.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.

https://reviews.freebsd.o= rg/D37514

has the changes for UPDATING. We lik= ely should document this in the RE-tasklis, with the caveat that the sequen= ce is 'create a new branch, trim UPDATING in -current only' rather = than the opposite to the stable/XX branch has the older data.
I think I trimmed the right amount.

We= likely should also have $SOMEBODY review the build / updating / etc instru= ctions at each release so we can keep them up to date as well as technology= evolves.

Warner
--00000000000041bc3d05ee82f5b5--