From nobody Mon Nov 28 06:34:45 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 4NLG0l2CbQz4jFjB for ; Mon, 28 Nov 2022 06:34:47 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NLG0l2012z4MFb for ; Mon, 28 Nov 2022 06:34:47 +0000 (UTC) (envelope-from netchild@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669617287; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aDtxaKi/4Nv9+qmLQmfItsYNBKebz9uN37pdlynvJq0=; b=FVLqnbBItRmWJFQFOpG4W8m+BbEAI/WktVjFijHgj3zzD7o76zY6dVPvX8M6PQzFiyMIfV Y82OE4mLCUIn1mvqPnhABaz0XgorWzQeY07ScfHo88AjzVpk6MQzRoY82qKO7OVRa1cPx2 jyw8rg+jHJWwcuRapEwxivBBPXKLjzxbP7+gs+7PJZ/VL1uN/LFAuUo6N7LndcIB6vKW30 WjH+RLXFvk53i+6b/FH/7RJiL1wB+3eG7tnUcxWK7lamcilIexi01E4n3/XKxLRmAJbgc1 QnkWp2lpu76+7waHdgO07JbB+ZDvkWly7k2g0rOmLLY6xAujd39mVu/E1r2X5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669617287; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aDtxaKi/4Nv9+qmLQmfItsYNBKebz9uN37pdlynvJq0=; b=yX3YhqRQlg+VNdCXiZ+byCUG5at5QSXF2Pkp+eSaCqNPKTMbxtyRf+EtEgn4sfg5rPnLMh aNlBnw6kpwAJ26BWMWqCPbvASLE+WBAhGHlYn6gEWVxaARVqdPPxDV5sy0yq1Mb/yv86ok ttrFDIZklZyUIYkDg5XE6xW4HtksBRjves7AjkMLZix6h7ps21j/6QIesyp0At4iB8wduE SERNTawjGa3j7cAYLK471O7zg3jxvMYURUzzqnJhFUGgxu3Z+9MmQ09tBCC2sikDz0+iOx UDY6Yb35FmknyVJi+xkID04VIHtsMbbt6LWEqUt5VVyjX+gvrJgfGNST6J1nJQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669617287; a=rsa-sha256; cv=none; b=OgmcV65p0vx1lxYXFzZASjp6X9RgO09twfcoNvlpydachvsJp1NYRujwnQQ5PwcV+8aHqr yykO0BxvniySKcMnJ3ZJXJwp45vuWiwEMkRfIOzld0Df8CvNEvBJRm2ZR1ogqlGcmhGLba NBxtyfKWtZBtI1+TOMfreKuFVZEFu9h15Gl9oqJ2Ous4drVIJ4GmOzcj5CxcIQbCnDqbIC S7a2y1dAM00wdFk3roHXGiUOA+RYQUA7W48fUvIULZvFeuFEhjHgD/3aHqUyLahtq1G87I 97zchFnNsnEVKKUXgjq6FLI/lCbabzsJICmpUWnfxD4fkg66oOuXCd/PeDaM2w== Received: from outgoing.leidinger.net (p5b165cc5.dip0.t-ipconnect.de [91.22.92.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) (Authenticated sender: netchild) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NLG0k5SRzz10Q7 for ; Mon, 28 Nov 2022 06:34:46 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from webmail.leidinger.net (localhost [127.0.0.1]) by outgoing.leidinger.net (Postfix) with ESMTP id 48C7C3725 for ; Mon, 28 Nov 2022 07:34:45 +0100 (CET) Received: from www (uid 80) (envelope-from netchild@freebsd.org) id 973a7 by webmail.leidinger.net (DragonFly Mail Agent v0.13+ on webmail.leidinger.net); Mon, 28 Nov 2022 07:34:45 +0100 Date: Mon, 28 Nov 2022 07:34:45 +0100 Message-ID: <20221128073445.Horde.UA46E1-_SRAS-yFXkM8r5q7@webmail.leidinger.net> From: Alexander Leidinger To: Warner Losh Cc: freebsd-arch@freebsd.org Subject: Re: How much to remove from UPDATING (was: Re: git: ff0c7816db69 - main - Remove UPDATING entries from old branches.) References: <202211250923.2AP9NakT073087@gitrepo.freebsd.org> <20221127223531.Horde.3qMyxtWhJEa3tXdg500ge5g@webmail.leidinger.net> In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_f5TKObAqox9-yUs7xdpdxiJ"; protocol="application/pgp-signature"; micalg=pgp-sha256 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 X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_f5TKObAqox9-yUs7xdpdxiJ Content-Type: multipart/alternative; boundary="=_X7mvh9gX9Jvp14GBBpwWt-V" This message is in MIME format. --=_X7mvh9gX9Jvp14GBBpwWt-V Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Description: Textnachricht Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Warner Losh (from Sun, 27 Nov 2022 20:12:08 -070= 0): > =C2=A0 > > On Sun, Nov 27, 2022 at 7:17 PM Warner Losh wrote= : > >> =C2=A0 >> >> On Sun, Nov 27, 2022 at 2:35 PM Alexander Leidinger=20=20 >>=20 wrote: >> >>> Quoting Warner Losh (from Fri, 25 Nov 2022=20=20 >>>=2009: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 are f= or >>>> 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 reas= on. >>> >>> 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=20=20 >>=20or two in a bit. >> =C2=A0 >> >>> I don't get the "more than just src updates" part. If we don'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 ''updating a=20=20 >>=20system 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 >>> 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. >> =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's >> officially supported by the project. Right now the 10.x=20=20 >>=20stuff is definitely >> too old. The 11.x stuff is borderline (but likely relevant),=20= =20 >>=20the 12.x stuff >> is still quite relevant. >> =C2=A0 >> We need to look at who is updating. Many people have only recentl= y >> updated from 11. Almost everybody has updated from 10 by now. Lot= s >> 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 >> updated to at least 12 as far as I've been able to tell. But=20= =20 >>=20many haven't >> jumped to 13 or current yet. >> =C2=A0 >> There are many people still updating their VMs from 11.=20=20 >>=20Traditionally, they >> wait until after 11.x goes unsupported before they update.=20=20 >>=20It's only been >> unsupported for just over 1 year. In the past, this is where=20= =20 >>=20upgrading is >> hitting full speed (I've received feedback in the past at=20=20 >>=20conferences that >> people often put it off for up to 18 months)... 10.x has=20=20 >>=20been unsupported >> for more than 3 years, so historically everybody has moved on. So= the > > =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=20=20 >>=20the logs, I've >> been not so great about this. Better at some times, worse at=20= =20 >>=20others.... > > =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=20=20 >>=20waning fast. 12.x >> entries are likely being used all the time by people=20=20 >>=20upgrading from still-supported >> releases. We've traditionally weighted towards retention because = the >> 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 b= e > 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 betwee= n. 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=20= =20 and=20keep 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=20=20 mind=20to live with this edge... Do we want to document that somewhere? RE-tasklist? Inside UPDATING=20=20 (top=20or bottom)? What about removing the entries of 10? Now or with next branch? I=20=20 would=20vote to do it now, what's done is done. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_X7mvh9gX9Jvp14GBBpwWt-V Content-Type: text/html; charset=utf-8 Content-Description: HTML-Nachricht Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

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

 

On Sun, Nov 27, 2022 at 7:17 PM Warne= r Losh <imp@bsdimp.com> wrote:<= /div>
 

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 are f= or
> 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 reas= on.

Reverted.

UPDATING as far back as stable/10 (=3D 4 major updates) is a little bit&nbs= p;
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&n= bsp;
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 <= br> 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 defin= itely
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<= /div>
updated to at least 12 as far as I've been able to tell. But many have= n'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 b= een
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 unsuppor= ted
for more than 3 years, so historically everybody has moved on. So the<= /div>
 
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 st= ill-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 =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 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 vot= e to do it now, what's done is done.

Bye,
Alexander.

--=_X7mvh9gX9Jvp14GBBpwWt-V-- --=_f5TKObAqox9-yUs7xdpdxiJ Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmOEVoQACgkQEg2wmwP4 2IYWvw//UPS4D/avmOXW6SzXFMvv9y5n0KqDhr3vhp8iQn1suDV3AhBStvc7yhlm iDV4OiOrfbLJ91/eaBWsxvo3VXGacYI6G3iMJtQY7+8mqbYrVQfaa5oVzg/52QFc dJ0FH5vKGqkXv72ggEzcaXtDlD0koBq4tf9zY45tgmqeyFNZuSGhkc/ZIUqZS8EM 3agTqDvtD6QCLStDzUHeiL/RMGDv4lEQN+kH4MALYO3Vbi2KzrFFMLsy+171y6ZJ 48lzHgPYL3oCwDS9zFZpD/J2sFeOsNdj7V2OzwunKUBO0XmGOvuiUvmOe/1+4BYQ qe05XYgok6eNGLLnoNGrQHSFV0HXCyA3KjgzNy8ABJNenGHNcQwXDIe3KLWHmsdr cpEzf0EOKnPsgzxVlix7wHONBdj4NY0cmfiNufXisIVEOtOO7UvEXpZRviJ2i0ig 90iNnoaRRYQjNrQ497XxMNvYEPp37aV0ncjPJFNIg8DLcE9ybytrFl/RgA+fxU7H MijNFSRL7syDOm04o9ReF/sW/uA99c7MEcEjWc6t8jF0ycky8FDpJoXEJD/klQ7s aQDKbItH6sgQLplfHnLAGeTEsFV3NNRL8MDsLoCxuiuD8S8oJ5rxSaZzVisFaD6y 9s99VwSdamcw3p+ED6NH/3NHT/TjhLhVSDSbQM1uedLRxPvnOWA= =0k0x -----END PGP SIGNATURE----- --=_f5TKObAqox9-yUs7xdpdxiJ--