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

Alexander Leidinger <[email protected]> Mon, 28 Nov 2022 07:34:45 +0100
Newsgroups	gmane.os.freebsd.architechture
Message-ID	<20221128073445.Horde.UA46E1-_SRAS-yFXkM8r5q7@webmail.leidinger.net>
  Quoting Warner Losh <[email protected]> (from Sun, 27 Nov 2022 20:12:08 -0700):

>  
>
>        On Sun, Nov 27, 2022 at 7:17 PM Warner Losh <[email protected]> wrote:
>
>>  
>>
>>              On Sun, Nov 27, 2022 at 2:35 PM Alexander Leidinger  
>> <[email protected]> wrote:
>>
>>> Quoting Warner Losh <[email protected]> (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.

Bye,
Alexander.
-- 
http://www.Leidinger.net [email protected]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [email protected]  : PGP 0x8F31830F9F2772BF
signature.asc (application/pgp-signature, 851 B)