!UNVBThoJtlIiVwiDjU:nixos.org

Staging

359 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/116 Servers

Load older messages


SenderMessageTime
13 Mar 2026
@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
28 Jun 2021
@grahamc:nixos.org@grahamc:nixos.org set the history visibility to "world_readable".15:07:04
@grahamc:nixos.org@grahamc:nixos.org changed the room name to "" from "".15:07:04
@grahamc:nixos.org@grahamc:nixos.org changed the room topic to "" from "".15:07:04
@grahamc:nixos.org@grahamc:nixos.org invited @mjolnir:nixos.orgmjolnir.15:07:15
@grahamc:nixos.org@grahamc:nixos.org invited @hexa:lossy.networkhexa.15:07:16
@mjolnir:nixos.orgmjolnir joined the room.15:07:16
@grahamc:nixos.org@grahamc:nixos.orgchanged room power levels.15:07:20
@hexa:lossy.networkhexa joined the room.15:07:20
@jonringer:matrix.orgjonringer joined the room.15:10:02
@vcunat:matrix.orgVladimír Čunát joined the room.15:10:25
@robert:funklause.dedotlambda joined the room.15:19:45
@voyager:t2bot.ioMatrix Traveler (bot) joined the room.15:26:55
@sternenseemann:systemli.orgsterni joined the room.16:09:42
@anodae:matrix.organodae joined the room.16:50:12
@andi:kack.itandi- joined the room.17:00:10
@thom:uint.onetomcur joined the room.19:45:28
@thom:uint.onetomcur changed their display name from Thom to tomcur.19:45:46

Show newer messages


Back to Room ListRoom Version: 6