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.

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?

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.