Re: How much to remove from UPDATING (was: Re: git: ff0c7816db69 - main - Remove UPDATING entries from old branches.)

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