depend-cleanup: remove entries from 2020 and 2021

[emaste]

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.

[imp]

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

[brooks]

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.

[imp]

In D46178#1052574, @brooks 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?

[brooks]

In D46178#1052583, @imp wrote:

In D46178#1052574, @brooks 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.