Re: How much to remove from UPDATING (was: Re: git: ff0c7816db69 - main - Remove UPDATING entries from old branches.)
- Reply: Warner Losh : "Re: How much to remove from UPDATING (was: Re: git: ff0c7816db69 - main - Remove UPDATING entries from old branches.)"
- In reply to: Warner Losh : "Re: How much to remove from UPDATING (was: Re: git: ff0c7816db69 - main - Remove UPDATING entries from old branches.)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 28 Nov 2022 06:34:45 UTC
Quoting Warner Losh <email@example.com> (from Sun, 27 Nov 2022 20:12:08 -0700): > > > On Sun, Nov 27, 2022 at 7:17 PM Warner Losh <firstname.lastname@example.org> wrote: > >> >> >> On Sun, Nov 27, 2022 at 2:35 PM Alexander Leidinger >> <email@example.com> wrote: >> >>> Quoting Warner Losh <firstname.lastname@example.org> (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 Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF