| 12 Oct 2025 |
 emily | by changing the reverse in the merge queue for staging | 16:00:15 |
| emily | like… we can even just insert the merges just-in-time if necessary. | 16:00:28 |
| emily | (or just boot it out and tell someone to run the periodic job) | 16:00:43 |
 Wolfgang Walther | I see, yes that could work. | 16:00:43 |
| emily | (since they'd need to resolve the conflict manually anyway) | 16:00:47 |
| emily | I think this would be simpler and more auditable than the "periodic merge via PR" flow | 16:01:07 |
| emily | we could reuse the cherry-pick backport action | 16:01:12 |
| emily | to point out the changes done | 16:01:17 |
| emily | which we'd need a separate version of otherwise, for the periodic merges via PR option | 16:01:25 |
| Wolfgang Walther | yeah, much smaller conflict diffs to look at, too. | 16:01:31 |
| emily | and the granularity is nice, because it means that contributors responsible for causing the conflicts can also be asked to resolve them. | 16:01:45 |
| Wolfgang Walther | periodic merge conflict diffs in a review comment cause me pain, because... it's likely they don't even fit. | 16:01:52 |
| emily | and there's not a big urgency to resolving them, because it "just" means stuff landing sooner | 16:01:57 |
| emily | rather than blocking staging/staging-next | 16:02:02 |
| Wolfgang Walther | yeah | 16:02:13 |
| Wolfgang Walther | This all depends on a CI job to reliably block "would be conflict" PRs on either side. | 16:02:41 |
| emily | the main thing that would change is that the repository history would get more cherry-picks and no "non-trivial" merges… but I'm inclined to think this is okay | 16:02:45 |
| emily | since we have a largely cherry-pick-y workflow anyway | 16:02:54 |
| emily | and we don't have to think about how GitHub is bad at handling merge commits in PRs etc. | 16:03:13 |
| Wolfgang Walther | yeah, that's a big plus. | 16:03:30 |
| emily | we also already do cherry-pick from staging/staging-next to master sometimes | 16:03:31 |
| emily | when it turns out that we actually want some staging PR in staging-next even though it causes rebuilds, to fix stuff | 16:03:42 |
| emily | or we want some low-rebuild commit from a staging PR into master now | 16:03:49 |
| Wolfgang Walther | we would still do the automated, never conflicted, periodic merges via PR, though. | 16:03:50 |
| emily | so this would be more consistent with that. | 16:03:53 |
| Wolfgang Walther | Because we need required status checks before actually pushing them. | 16:04:01 |
| Wolfgang Walther | otherwise we can still introduce breakage. | 16:04:06 |
| emily | hmm, right, because there are "semantic merge conflicts". but those at least won't involve Git-level conflicts, so less of a pain | 16:04:30 |
| Wolfgang Walther | but we don't need any of the conflict handling stuff in these PRs. | 16:04:32 |
| emily | we could eliminate those by just… running the checks for multiple branches in the queue… but that might be excessive. | 16:04:45 |
