| 13 Mar 2026 |
emily | visibility and auditing is pretty awful right now | 12:07:35 |
Ramses 🇵🇸 | Yeah, but the merge needs to arbitrage between the two (fix on -next, regular bump on master) | 12:07:40 |
Ramses 🇵🇸 | I noticed a prior issue from you about that, while searching for docs on how to do this merge | 12:08:12 |
Ramses 🇵🇸 | That would make things a lot more transparent (but potentially also a bit more laborious) | 12:08:39 |
Ramses 🇵🇸 | I wasn't totally sure whether we were, so good to know! 😁 | 12:09:26 |
emily | yeah, making the workflow not painful is the main consideration. I think having a pre-made ref you can push to would help offset that | 12:11:29 |
emily | as well as specifically avoiding mass rebuilds and eval issues percolating to -next which sucks | 12:11:55 |
emily | I've thought more lately about how we can avoid conflicts arising in the first place though | 12:12:07 |
emily | the ideal would be that we don't get two PRs that don't know about each other both landing in different "timelines" at all | 12:12:38 |
emily | multiple merge queues kind of dampen the benefit of having them | 12:13:52 |
Ramses 🇵🇸 | Yeah, AFAICT, the commit to switch kitty to a non-EOL go could've gone to master, which would've avoided this conflict and discussion. But maybe there were other reasons why it didn't, I don't have the context | 14:20:46 |
Ramses 🇵🇸 | But in general indeed it's hard to know when you make a PR to master, that there are any conflicting changes on staging(-next). And even if we detected this in CI, I don't think it's always possible to modify the changes such that they cleanly apply on both branches | 14:22:24 |
emily | well, I had some ideas for making it so that they always can :) but which ones are practical, not sure | 15:52:03 |
emily | at the very least having to explicitly handle it when such a situation arrives rather than being able to sleepwalk into it would be goo | 15:52:22 |
emily | * at the very least having to explicitly handle it when such a situation arrives rather than being able to sleepwalk into it would be good | 15:52:33 |
Ramses 🇵🇸 | In reply to @emilazy:matrix.org at the very least having to explicitly handle it when such a situation arrives rather than being able to sleepwalk into it would be good Definitely | 17:58:55 |