Date: Mon, 28 Nov 2022 07:34:45 +0100 From: Alexander Leidinger <netchild@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arch@freebsd.org Subject: Re: How much to remove from UPDATING (was: Re: git: ff0c7816db69 - main - Remove UPDATING entries from old branches.) Message-ID: <20221128073445.Horde.UA46E1-_SRAS-yFXkM8r5q7@webmail.leidinger.net> In-Reply-To: <CANCZdfqDuCQS26_2VSSG9Pyw9QrTeRtY%2Bx3Wn48UhXGvCyKcQQ@mail.gmail.com> References: <202211250923.2AP9NakT073087@gitrepo.freebsd.org> <CANCZdfq%2BAVGWa91Cv80t60jKAmw0UwoTVNFeOGRjOhAPjsJH%2Bw@mail.gmail.com> <20221127223531.Horde.3qMyxtWhJEa3tXdg500ge5g@webmail.leidinger.net> <CANCZdfruzk8Ruxo7MQ3zTwNZbow0i%2BBdvunqNV5mM=FK-WDGAQ@mail.gmail.com> <CANCZdfqDuCQS26_2VSSG9Pyw9QrTeRtY%2Bx3Wn48UhXGvCyKcQQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <imp@bsdimp.com> (from Sun, 27 Nov 2022 20:12:08 -070= 0): > =C2=A0 > > On Sun, Nov 27, 2022 at 7:17 PM Warner Losh <imp@bsdimp.com> wrote= : > >> =C2=A0 >> >> On Sun, Nov 27, 2022 at 2:35 PM Alexander Leidinger=20=20 >>=20<netchild@freebsd.org> wrote: >> >>> Quoting Warner Losh <imp@bsdimp.com> (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 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">; <html> <head> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"> <title></title> </head> <body style=3D"font-family:Arial;font-size:14px"> <p>Quoting Warner Losh <<a href=3D"mailto:imp@bsdimp.com">imp@bsdimp.com= </a>> (from Sun, 27 Nov 2022 20:12:08 -0700):</p> <blockquote style=3D"border-left:2px solid blue;margin-left:2px;padding-lef= t:12px;" type=3D"cite"> <div dir=3D"ltr"> <div dir=3D"ltr"> </div> <br> <div class=3D"gmail_quote"> <div class=3D"gmail_attr" dir=3D"ltr">On Sun, Nov 27, 2022 at 7:17 PM Warne= r Losh <<a href=3D"mailto:imp@bsdimp.com">imp@bsdimp.com</a>> wrote:<= /div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir=3D"ltr"> <div dir=3D"ltr"> </div> <br> <div class=3D"gmail_quote"> <div class=3D"gmail_attr" dir=3D"ltr">On Sun, Nov 27, 2022 at 2:35 PM Alexa= nder Leidinger <<a href=3D"mailto:netchild@freebsd.org" target=3D"_blank= ">netchild@freebsd.org</a>> wrote:</div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> <p>Quoting Warner Losh <<a href=3D"mailto:imp@bsdimp.com" target=3D"_bla= nk">imp@bsdimp.com</a>> (from Fri, 25 Nov 2022 09:41:28 -0700):<br> <br> > Please revert this. We keep older updating entries on purpose. You pur= ged<br> > way too much. Let's chat about how much to remove in arch@. They are f= or<br> > more than just source updates, so your reasoning is wrong. They are al= so<br> > there for users updating their products which can have a larger leap i= n<br> > time. We've traditionally kept closer to 5-10 years here for that reas= on.<br> <br> Reverted.<br> <br> UPDATING as far back as stable/10 (=3D 4 major updates) is a little bit&nbs= p;<br> excessive (more than 9 years of development work so far), isn't it?</p> </blockquote> <div> </div> <div>Yes. It's about one release too old, maybe two. More on one or two in = a bit.</div> <div> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> <p>I don't get the "more than just src updates" part. If we don't talk = ;<br> about the source code, isn't src/UPATING not the wrong place to store = <br> it?</p> </blockquote> <div> </div> <div>More than just 'make buildworld updating' or ''updating a system from = src'</div> <div>is what I mean.</div> <div> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> <p>In terms of updating products, I understand that updating them every 2&n= bsp;<br> years may be a little bit expensive/excessive for some vendors, but <b= r> taking every UPDATING from every stable branch in-between doesn't look = ;<br> too much time consuming to me. And compared to the huge amount of <br> changes between N-2 and N... taking UPDATING from all stable branches = <br> in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish, <br> nearly 10 years is ... ugh ... a life-time or two in the computer <br> world. If we look e.g. at the PlayStation (yes, just one of the <br> products which has FreeBSD inside, but personally I consider it one of = ;<br> 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 <br> view), there are around 6 years in-between models, and they surely <br= > haven't started developing a month before the release date.</p> </blockquote> <div> </div> <div>So, let's look at what it's used for to see how much we need. If you</= div> <div>look at it that way, you'll see that we're not crazy lagging.</div> <div> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> <p>So where do we draw the line for UPDATING, 2 major versions (~4 <br= > years), 3 major versions (~6 years)? ~10 years (~5 major versions) <br= > looks overly excessive to me. That's not something you want to try to = <br> catch up, that's rather a new development than a catch-up</p> </blockquote> <div> </div> <div>OK. Traditionally we've lagged a major release or two from what's</div= > <div>officially supported by the project. Right now the 10.x stuff is defin= itely</div> <div>too old. The 11.x stuff is borderline (but likely relevant), the 12.x = stuff</div> <div>is still quite relevant.</div> <div> </div> <div>We need to look at who is updating. Many people have only recently</di= v> <div>updated from 11. Almost everybody has updated from 10 by now. Lots</di= v> <div>of people are using 12 and it's still supported.</div> <div> </div> <div>Most of the folks that have source products with lots of changes have<= /div> <div>updated to at least 12 as far as I've been able to tell. But many have= n't</div> <div>jumped to 13 or current yet.</div> <div> </div> <div>There are many people still updating their VMs from 11. Traditionally,= they</div> <div>wait until after 11.x goes unsupported before they update. It's only b= een</div> <div>unsupported for just over 1 year. In the past, this is where upgrading= is</div> <div>hitting full speed (I've received feedback in the past at conferences = that</div> <div>people often put it off for up to 18 months)... 10.x has been unsuppor= ted</div> <div>for more than 3 years, so historically everybody has moved on. So the<= /div> </div> </div> </blockquote> <div> </div> <div>I can't do math.... More than 4 years...</div> <div> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir=3D"ltr"> <div class=3D"gmail_quote"> <div>10.x entries are definitely stale... The 11 entries are on the edge...= I'd</div> <div>normally have removed the 10.x entries when 13 was branched, but</div> <div>I was asleep at the wheel this time.... Though looking at the logs, I'= ve</div> <div>been not so great about this. Better at some times, worse at others...= .</div> </div> </div> </blockquote> <div> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir=3D"ltr"> <div class=3D"gmail_quote"> <div>So in my opinion, 10.x entries should have already been gone. 11.x</di= v> <div>entries are likely useful enough to keep, but they are waning fast. 12= .x</div> <div>entries are likely being used all the time by people upgrading from st= ill-supported</div> <div>releases. We've traditionally weighted towards retention because the</= div> <div>cost of retention has been super low.</div> <div> </div> <div>This suggests we delete up to the 11 branch point now, and to the 12</= div> <div>branch point when 14 branches in 6 months or so...</div> </div> </div> </blockquote> <div> </div> <div>13.x was branched about 6.5 years ago. When 14 is branched, it will be= </div> <div>7 years and we'll removing the to the 12 branch point which will be</d= iv> <div>four and half years. This seems like a good range to oscillate between= .</div> </div> </div> </blockquote> <p><br> If I understand it correctly, you want to target a policy of:<br> 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.<br> <br> stable/14 -> keep 13+12 and delete 11.<br> <br> Basically we both are aligned and think N-2 is on the edge. I don't mind to= live with this edge...<br> <br> Do we want to document that somewhere? RE-tasklist? Inside UPDATING (top or= bottom)?<br> <br> 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.<br> <br> Bye,<br> Alexander.<br></p> <div><a href=3D"http://www.Leidinger.net" target=3D"_blank">http://www.Leid= inger.net</a> <a href=3D"mailto:Alexander@Leidinger.net">Alexander@Leidinge= r.net</a>: PGP 0x8F31830F9F2772BF<br> <a href=3D"http://www.FreeBSD.org" target=3D"_blank">http://www.FreeBSD.org= </a> <a href=3D"mailto:netchild@FreeBSD.org">netchild@FreeBSD.= org</a> : PGP 0x8F31830F9F2772BF</div> </body> </html> --=_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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20221128073445.Horde.UA46E1-_SRAS-yFXkM8r5q7>