Date: Sun, 27 Nov 2022 19:17:21 -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: <CANCZdfruzk8Ruxo7MQ3zTwNZbow0i%2BBdvunqNV5mM=FK-WDGAQ@mail.gmail.com> In-Reply-To: <20221127223531.Horde.3qMyxtWhJEa3tXdg500ge5g@webmail.leidinger.net> References: <202211250923.2AP9NakT073087@gitrepo.freebsd.org> <CANCZdfq%2BAVGWa91Cv80t60jKAmw0UwoTVNFeOGRjOhAPjsJH%2Bw@mail.gmail.com> <20221127223531.Horde.3qMyxtWhJEa3tXdg500ge5g@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000018842805ee7e79c4 Content-Type: text/plain; charset="UTF-8" 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 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... Warner --00000000000018842805ee7e79c4 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 2:35 PM Alexa= nder Leidinger <<a href=3D"mailto:netchild@freebsd.org" target=3D"_blank= ">netchild@freebsd.org</a>> wrote:<br></div><blockquote class=3D"gmail_q= uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2= 04);padding-left:1ex">Quoting Warner Losh <<a href=3D"mailto:imp@bsdimp.= com" target=3D"_blank">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?<br>= </blockquote><div><br></div><div>Yes. It's about one release too old, m= aybe two. More on one or two in a bit.<br></div><div>=C2=A0</div><blockquot= e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s= olid rgb(204,204,204);padding-left:1ex"> I don't get the "more than just src updates" part. If we don&= #39;t talk=C2=A0 <br> about the source code, isn't src/UPATING not the wrong place to store= =C2=A0 <br> it?<br></blockquote><div><br></div><div>More than just 'make buildworld= updating' or ''updating a system from src'</div><div>is wh= at I mean.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl= e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin= g-left:1ex"> 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 <= br> 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 <b= r> haven't started developing a month before the release date.<br></blockq= uote><div><br></div><div>So, let's look at what it's used for to se= e how much we need. If you</div><div>look at it that way, you'll see th= at we're not crazy lagging.<br></div><div>=C2=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"> 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 <b= r> 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</blockquote><= div><br></div><div>OK. Traditionally we've lagged a major release or tw= o from what's</div><div>officially supported by the project. Right now = the 10.x stuff is definitely</div><div>too old. The 11.x stuff is borderlin= e (but likely relevant), the 12.x stuff</div><div>is still quite relevant.<= br></div><div><br></div><div>We need to look at who is updating. Many peopl= e have only recently</div><div>updated from 11. Almost everybody has update= d from 10 by now. Lots</div><div>of people are using 12 and it's still = supported.</div><div><br></div><div>Most of the folks that have source prod= ucts 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 c= urrent yet.</div><div><br></div><div>There are many people still updating t= heir VMs from 11. Traditionally, they</div><div>wait until after 11.x goes = unsupported before they update. It's only been</div><div>unsupported fo= r just over 1 year. In the past, this is where upgrading is</div><div>hitti= ng 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 unsu= pported</div><div>for more than 3 years, so historically everybody has move= d on. So the</div><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 e= ntries when 13 was branched, but</div><div>I was asleep at the wheel this t= ime.... Though looking at the logs, I've</div><div>been not so great ab= out this. Better at some times, worse at others....</div><div><br></div><di= v>So in my opinion, 10.x entries should have already been gone. 11.x</div><= 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 still-supported</div><div>releases. We've traditionally weighted t= owards retention because the</div><div>cost of retention has been super low= .</div><div><br></div><div>This suggests we delete up to the 11 branch poin= t now, and to the 12</div><div>branch point when 14 branches in 6 months or= =C2=A0so...</div><div><br></div><div>Warner<br></div><div><br></div></div><= /div> --00000000000018842805ee7e79c4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfruzk8Ruxo7MQ3zTwNZbow0i%2BBdvunqNV5mM=FK-WDGAQ>