well, I have ideas that are varying degrees of radical 😅 there are lots of ways we could get rid of the manual merge conflict resolution dance but the one that would streamline the -next rebuild avoidance dance looks like:

we only have one true branch (per release), master, and we conditionalize big rebuilds with feature flags conditionals like version = if ... stage... then "3.0" else "2.1";. preparing a new -next is just increasing the "epoch" past all currently staged changes. (could also make it a bit easier for us to say "uh, big security fix, let's roll a cycle without this risky stuff")

to do clean-up and reduce the tedium of authoring changes, we have a script that automatically adds these conditionals in a separate commit on top of your "staging-based" commit. merge queue checks you didn't break eval on any epoch and that the staging commits don't cause rebuilds at the relevant epoch. then -next/staging branches just undo those staging commits so you have base for changes and we merge them in for clean-up once a cycle completes. you only have to do manual "conflict resolution" when there's a genuine divergence between the branches and the script can't automatically do it, and it happens in the relevant PRs.

so here you'd add the patch, the script would add the conditionals, and staging vs. -next would just be a question of what epoch you assign it to. you can always see from master when there's changes in-flight, and clean-up happens automatically

should probably conditionalize and revert on staging

Conditionalized.

[git PR] should probably conditionalize and revert on staging

Conditionalized.