Date: Sun, 27 Nov 2022 20:12:08 -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: <CANCZdfqDuCQS26_2VSSG9Pyw9QrTeRtY%2Bx3Wn48UhXGvCyKcQQ@mail.gmail.com> In-Reply-To: <CANCZdfruzk8Ruxo7MQ3zTwNZbow0i%2BBdvunqNV5mM=FK-WDGAQ@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000010c4a005ee7f3dbf Content-Type: text/plain; charset="UTF-8" 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. Warner --00000000000010c4a005ee7f3dbf 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 7:17 PM Warne= r Losh <<a href=3D"mailto:imp@bsdimp.com">imp@bsdimp.com</a>> wrote:<= br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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 Alexander Leidinger &= lt;<a href=3D"mailto:netchild@freebsd.org" target=3D"_blank">netchild@freeb= sd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m= argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></div></blockquote><div><br></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(2= 04,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 loo= king at the logs, I've</div><div>been not so great about this. Better a= t some times, worse at others....</div></div></div></blockquote><div><br></= div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-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 alre= ady 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'v= e traditionally weighted towards retention because the</div><div>cost of re= tention has been super low.</div><div><br></div><div>This suggests we delet= e 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><b= r></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 poin= t which will be</div><div>four and half years. This seems like a good range= to oscillate between.</div><div><br></div><div>Warner <br></div></div></di= v> --00000000000010c4a005ee7f3dbf--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqDuCQS26_2VSSG9Pyw9QrTeRtY%2Bx3Wn48UhXGvCyKcQQ>