| 12 Oct 2025 |
 emily | it means the conflicts can be resolved per-PR | 15:56:03 |
| emily | rather than all at once | 15:56:08 |
| emily | I don't understand | 15:56:22 |
| emily | that's exactly the case of periodic merges failing | 15:56:26 |
| emily | it would be far more auditable and granular than those | 15:56:35 |
 K900 | I'd much rather resolve the conflicts all at once than have random people make three different PRs and compare them against each other | 15:56:58 |
| emily | this would eliminate the conflicts | 15:57:17 |
| emily | there would never be any | 15:57:21 |
| emily | like, exactly when someone would have to manually resolve/check the conflict on staging, the merge would say "this conflicts with staging – target staging instead", and if you need the PR to land in master sooner than that, you would then open a cherry-pick from staging back to master, resolving the conflict | 15:57:57 |
| emily | which a committer could still do – but a contributor could also do, just like with backports to release branches | 15:58:08 |
| emily | it ensures that every change is always targeting the "latest state" whenever there would otherwise be conflicts | 15:58:23 |
| emily | and we never have "master does X, staging does Y, they are incompatible, we find out 6 hours later" | 15:58:31 |
 Wolfgang Walther | This doesn't solve the case of "A is merged into master, in the 6 hour window where A has not made its way to staging, B is merged into staging; A and B conflict". | 15:59:44 |
| Wolfgang Walther | So it would not eliminate all of these cases, but probably reduce them a lot. | 15:59:57 |
| emily | we can solve that too | 16:00:08 |
| 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 |
