Date: Mon, 28 Nov 2022 00:20:49 -0700 From: Warner Losh <imp@bsdimp.com> To: Alexander Leidinger <netchild@freebsd.org> 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: <CANCZdfpT-GSr0aTvEH-w5B_6SP06u3tAvNtCiKY3JM9QzQ4DZA@mail.gmail.com> In-Reply-To: <20221128073445.Horde.UA46E1-_SRAS-yFXkM8r5q7@webmail.leidinger.net> 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> <20221128073445.Horde.UA46E1-_SRAS-yFXkM8r5q7@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000009a4f5705ee82b6c2 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 27, 2022 at 11:34 PM Alexander Leidinger <netchild@freebsd.org> wrote: > Quoting Warner Losh <imp@bsdimp.com> (from Sun, 27 Nov 2022 20:12:08 > -0700): > > > > On Sun, Nov 27, 2022 at 7:17 PM Warner Losh <imp@bsdimp.com> wrote: > >> >> >> On Sun, Nov 27, 2022 at 2:35 PM Alexander 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 >>> 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 <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Sun, Nov 27, 2022 at 11:34 PM Alex= ander Leidinger <<a href=3D"mailto:netchild@freebsd.org">netchild@freebs= d.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:= 1ex"><u></u> <div style=3D"font-family:Arial;font-size:14px"> <p>Quoting Warner Losh <<a href=3D"mailto:imp@bsdimp.com" target=3D"_bla= nk">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">=C2=A0</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" target=3D"_blank">imp@bsdimp.c= om</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">=C2=A0</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 a= re for<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 = reason.<br> <br> Reverted.<br> <br> UPDATING as far back as stable/10 (=3D 4 major updates) is a little bit=C2= =A0<br> excessive (more than 9 years of development work so far), isn't it?</p> </blockquote> <div>=C2=A0</div> <div>Yes. It's about one release too old, maybe two. More on one or two= in a bit.</div> <div>=C2=A0</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 d= on't talk=C2=A0<br> about the source code, isn't src/UPATING not the wrong place to store= =C2=A0<br> it?</p> </blockquote> <div>=C2=A0</div> <div>More than just 'make buildworld updating' or ''updatin= g a system from src'</div> <div>is what I mean.</div> <div>=C2=A0</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= =C2=A0<br> years may be a little bit expensive/excessive for some vendors, but=C2=A0<b= r> taking every UPDATING from every stable branch in-between doesn't look= =C2=A0<br> too much time consuming to me. And compared to the huge amount of=C2=A0<br> changes between N-2 and N... taking UPDATING from all stable branches=C2=A0= <br> in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish,=C2=A0<br> nearly 10 years is ... ugh ... a life-time or two in the computer=C2=A0<br> world. If we look e.g. at the PlayStation (yes, just one of the=C2=A0<br> products which has FreeBSD inside, but personally I consider it one of=C2= =A0<br> 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<br> view), there are around 6 years in-between models, and they surely=C2=A0<br= > haven't started developing a month before the release date.</p> </blockquote> <div>=C2=A0</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>=C2=A0</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=C2=A0<br= > years), 3 major versions (~6 years)? ~10 years (~5 major versions)=C2=A0<br= > looks overly excessive to me. That's not something you want to try to= =C2=A0<br> catch up, that's rather a new development than a catch-up</p> </blockquote> <div>=C2=A0</div> <div>OK. Traditionally we've lagged a major release or two from what= 9;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>=C2=A0</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>=C2=A0</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 = haven't</div> <div>jumped to 13 or current yet.</div> <div>=C2=A0</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 on= ly been</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 conferen= ces 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>=C2=A0</div> <div>I can't do math.... More than 4 years...</div> <div>=C2=A0</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...= =C2=A0 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&= #39;ve</div> <div>been not so great about this. Better at some times, worse at others...= .</div> </div> </div> </blockquote> <div>=C2=A0</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 t= he</div> <div>cost of retention has been super low.</div> <div>=C2=A0</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=C2=A0so...</div> </div> </div> </blockquote> <div>=C2=A0</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 b= e</div> <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 min= d 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.</p></div></blockquote><div><br></d= iv><div>I think we should remove entries before the 11 branch now. I'll= create a review with that.</div><div><br></div><div>Warner <br></div></div= ></div> --0000000000009a4f5705ee82b6c2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpT-GSr0aTvEH-w5B_6SP06u3tAvNtCiKY3JM9QzQ4DZA>