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

On Mon, Nov 28, 2022 at 12:20 AM Warner Losh <imp@bsdimp.com> wrote:

>
>
> 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.
>

https://reviews.freebsd.org/D37514

has the changes for UPDATING. We likely should document this in the
RE-tasklis, with the caveat that the sequence is 'create a new branch, trim
UPDATING in -current only' rather than the opposite to the stable/XX branch
has the older data.

I think I trimmed the right amount.

We likely should also have $SOMEBODY review the build / updating / etc
instructions at each release so we can keep them up to date as well as
technology evolves.

Warner