| 12 Oct 2025 |
 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 |
| Wolfgang Walther | Re-using the existing backport tools; I like. This makes any investments into these pay off in more ways. | 16:05:50 |
| emily | FWIW, we could still do the fancy "PR with the conflicts up so you can review them before diving in" thing, by making it work for all label-based backports. | 16:06:35 |
| emily | i.e., a backport label never fails, it just sometimes produces a PR with conflict markers. | 16:06:43 |
| emily | and then that would also work for backports to release branches, which would be nice. | 16:06:52 |
| emily | so yeah, I think a backporting approach is strictly more consistent/makes better use of our tooling investments. | 16:07:12 |
| Wolfgang Walther | So I guess this will be the first thing to work on. This can be non-blocking and purely informative at first. Once it works, it can be enforced. | 16:08:40 |
| emily | that seems useful regardless of workflow | 16:14:49 |
| emily | but … it'd be good to know if K900 is thinking of something we're missing here wrt the workflow, too | 16:15:07 |
| emily | (I am guessing just a communication problem about what the flow would actually be but I could be wrong) | 16:15:32 |
 K900 | I'm at the vet, will write longer words in a bit | 16:15:33 |
 Yureka (she/her) | I like the idea | 16:25:30 |
| Yureka (she/her) | So, spectrum really needs a fix for pkgsMusl.iproute2 in the current staging-next | 16:26:31 |
| Yureka (she/her) | * anyways
So, spectrum really needs a fix for pkgsMusl.iproute2 in the current staging-next
| 16:26:39 |
| Yureka (she/her) | it's expensive rebuilds-wise | 16:26:40 |
| Yureka (she/her) | or we can make it conditional and then immediately revert and do a proper fix on staging yada yada | 16:27:02 |
