!UNVBThoJtlIiVwiDjU:nixos.org

Staging

352 Members
Staging merges | Running staging cycles: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+head%3Astaging-next+head%3Astaging-next-25.11 | Review Reports: https://malob.github.io/nix-review-tools-reports/113 Servers

Load older messages


SenderMessageTime
13 Mar 2026
@emilazy:matrix.orgemilyvisibility and auditing is pretty awful right now12:07:35
@rvdp:infosec.exchangeRamses 🇵🇸Yeah, but the merge needs to arbitrage between the two (fix on -next, regular bump on master)12:07:40
@rvdp:infosec.exchangeRamses 🇵🇸I noticed a prior issue from you about that, while searching for docs on how to do this merge12:08:12
@rvdp:infosec.exchangeRamses 🇵🇸That would make things a lot more transparent (but potentially also a bit more laborious)12:08:39
@rvdp:infosec.exchangeRamses 🇵🇸I wasn't totally sure whether we were, so good to know! 😁12:09:26
@emilazy:matrix.orgemilyyeah, making the workflow not painful is the main consideration. I think having a pre-made ref you can push to would help offset that12:11:29
@emilazy:matrix.orgemilyas well as specifically avoiding mass rebuilds and eval issues percolating to -next which sucks12:11:55
@emilazy:matrix.orgemilyI've thought more lately about how we can avoid conflicts arising in the first place though12:12:07
@emilazy:matrix.orgemilythe ideal would be that we don't get two PRs that don't know about each other both landing in different "timelines" at all12:12:38
@emilazy:matrix.orgemilymultiple merge queues kind of dampen the benefit of having them12:13:52
@rvdp:infosec.exchangeRamses 🇵🇸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 context14:20:46
@rvdp:infosec.exchangeRamses 🇵🇸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 branches14:22:24
@emilazy:matrix.orgemilywell, I had some ideas for making it so that they always can :) but which ones are practical, not sure15:52:03
@emilazy:matrix.orgemilyat the very least having to explicitly handle it when such a situation arrives rather than being able to sleepwalk into it would be goo15:52:22
@emilazy:matrix.orgemily* at the very least having to explicitly handle it when such a situation arrives rather than being able to sleepwalk into it would be good15:52:33
@rvdp:infosec.exchangeRamses 🇵🇸
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

There are no newer messages yet.


Back to Room ListRoom Version: 6