| 12 Oct 2025 |
 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 |
| Yureka (she/her) | this is the high rebuilds solution: https://github.com/NixOS/nixpkgs/pull/451338 | 16:27:11 |
| Yureka (she/her) | * or we can make it conditional and then immediately revert and do a proper fix on staging yada yada | 16:27:29 |
| Yureka (she/her) | someone merged it | 16:53:56 |
| Yureka (she/her) | we can still revert and go the low rebuild count path | 16:54:18 |
| Yureka (she/her) | * | 16:54:23 |
