| 13 Mar 2026 |
 Ramses 🇵🇸 | Seems like the kind of situation where you end up annoying someone in any case | 12:03:16 |
 emily | yeah I don't think you did anything wrong :) | 12:03:43 |
| Ramses 🇵🇸 | I fully agree that we should avoid pinning, but a merge commit in -next without a PR to give the maintainers a chance to weigh in, didn't seem like the right place to fix that | 12:05:15 |
| emily | procedurally I err very much in favour of stuff landing on staging, because the workload is high and the contributors are deeply knowledgeable on average and being a time-sensitive maintainer of last resort is no fun if it also lacks the authority to make judgement calls | 12:05:24 |
| emily | but we're violently agreeing I think 😆 | 12:05:46 |
| emily | IMO it was the -next commit that made that call rather than the merge. but those aren't great for visibility for maintainers especially if they're pushed directly, yeah | 12:06:37 |
| emily | (thank you for doing the merge!) | 12:06:45 |
| emily | we really need to move to a PR-only workflow for staging, including for merges. I'll hopefully write up plans for that soon... | 12:07:23 |
| 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 |
| 28 Jun 2021 |
|  @grahamc:nixos.org set the history visibility to "world_readable". | 15:07:04 |
| @grahamc:nixos.org changed the room name to "" from "". | 15:07:04 |
| @grahamc:nixos.org changed the room topic to "" from "". | 15:07:04 |
| @grahamc:nixos.org invited  mjolnir. | 15:07:15 |
| @grahamc:nixos.org invited  hexa. | 15:07:16 |
| mjolnir joined the room. | 15:07:16 |
