Page MenuHomeFreeBSD

depend-cleanup: remove entries from 2020 and 2021
ClosedPublic

Authored by emaste on Jul 29 2024, 5:10 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 13, 10:02 AM
Unknown Object (File)
Thu, Nov 7, 11:46 PM
Unknown Object (File)
Thu, Nov 7, 10:14 PM
Unknown Object (File)
Oct 17 2024, 3:03 AM
Unknown Object (File)
Oct 17 2024, 3:03 AM
Unknown Object (File)
Oct 17 2024, 3:03 AM
Unknown Object (File)
Oct 17 2024, 2:23 AM
Unknown Object (File)
Sep 22 2024, 12:34 PM
Subscribers

Details

Summary
> These tests increase the build time (albeit by a small amount), so
> they should be removed once enough time has passed and it is extremely
> unlikely anyone would try a NO_CLEAN build against an object tree from
> before the related change.

The comment suggests a year is a reasonable period but we'll be somewhat
more conservative for now, in part so that we retain different examples
of special cases.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Yea, I was thinking 'branch points' are a good time to clear this out...
A year seems about right-ish, though I was thinking maybe 6 months will suffice. There's very little benefit for an incremental build > 3 months since we update clang that often....

This revision is now accepted and ready to land.Jul 29 2024, 5:35 PM

I think a year is fine if we're not going to go all the way to "latest change on the prior branch".

LLVM releases are every 6 months with updates trickling in throughout that period, but mostly toward the front half and usually not things that effect more than a few files (often only single architectures).

From a downstream (CheriBSD) perspective, we'd ideally not be dealing with more than 6 months of changes, but we're bursty and sometimes do things out of order (e.g., landing all of libsys at cherry-picks so I could deal with any reworking required before merging across it more conventionally). I think this argues for something closer to 1 year.

I think a year is fine if we're not going to go all the way to "latest change on the prior branch".

LLVM releases are every 6 months with updates trickling in throughout that period, but mostly toward the front half and usually not things that effect more than a few files (often only single architectures).

From a downstream (CheriBSD) perspective, we'd ideally not be dealing with more than 6 months of changes, but we're bursty and sometimes do things out of order (e.g., landing all of libsys at cherry-picks so I could deal with any reworking required before merging across it more conventionally). I think this argues for something closer to 1 year.

Three choices then: (a) 1 year, all branches, maybe a bit more from time to time, but don't count on it. or (b) 1 year or back to where the stable branch forked from main, which ever is longer and 1 year on main or (c) stable like (B) but main goes back to oldest supported stable branch point.

I rather like (a) since it's simplest, and there's not much gain for (b) or (c) since it's just for incremental builds and > 1 year between incremental builds means the benefit from an incremental build diminish to almost 0. Would that match cheri well given that 6 months seems too short?

In D46178#1052583, @imp wrote:

I think a year is fine if we're not going to go all the way to "latest change on the prior branch".

LLVM releases are every 6 months with updates trickling in throughout that period, but mostly toward the front half and usually not things that effect more than a few files (often only single architectures).

From a downstream (CheriBSD) perspective, we'd ideally not be dealing with more than 6 months of changes, but we're bursty and sometimes do things out of order (e.g., landing all of libsys at cherry-picks so I could deal with any reworking required before merging across it more conventionally). I think this argues for something closer to 1 year.

Three choices then: (a) 1 year, all branches, maybe a bit more from time to time, but don't count on it. or (b) 1 year or back to where the stable branch forked from main, which ever is longer and 1 year on main or (c) stable like (B) but main goes back to oldest supported stable branch point.

I rather like (a) since it's simplest, and there's not much gain for (b) or (c) since it's just for incremental builds and > 1 year between incremental builds means the benefit from an incremental build diminish to almost 0. Would that match cheri well given that 6 months seems too short?

I think a year will work for us. We've also go the ability to force a clean rebuild in our standard tooling so it's not the end of the world if we get too far behind or encounter people are unlikely to hit upstream. I just think 6 months would be a bit too quick given the time dilation we cause ourselves.