| 27 Mar 2026 |
 emily | since right now it spawns tens of thousands of Linux jobs for very close commits on nixos:unstable and nixpkgs:unstable | 11:15:21 |
 K900 | Probably | 11:15:24 |
| emily | maybe not relevant with the new runner, but | 11:15:28 |
| K900 | We're not running the new runner yet though | 11:15:39 |
| K900 | Or are we | 11:15:40 |
| emily | well, either way :) either we aren't and it should help or we are and it should help only a little(?) | 11:23:08 |
| emily | the main complication I've thought of is that we'd want to prefix the staging-next job names for easier comparisons | 11:41:14 |
| emily | but I kept wanting to check if there are others I haven't thought of here, and kept forgetting to | 11:41:33 |
| emily | anyway, this seems okay to me. though ofc the job choices are really arbitrary. can probably merge once I'm at a computer | 11:43:04 |
| emily | tbh I feel like the only reason to split the channels is to not block Linux on Darwin so if we had merged jobsets it seems like the Linux portion of nixpkgs-unstable blockers could just be the same as nixos-unstable i.e. pull the NixOS tests in. but that's a separate matter | 11:44:51 |
 Vladimír Čunát | OK, merging. Let's try and see. | 11:45:16 |
| emily | if you can think of any reasons merging-jobsets-but-not-blocker-jobs would be a disaster let me know because otherwise I might take a look at that Perl script 😅 | 11:50:44 |
| Vladimír Čunát | I don't expect a disaster. | 11:52:51 |
| Vladimír Čunát | Some scripting around the "all other jobs are finished" condition. | 11:53:17 |
| Vladimír Čunát | And we would be breaking people who referenced the removed jobsets on Hydra. (e.g. with the recent renaming, Hydra is still providing http redirects, but we wouldn't get that here) | 11:54:24 |
| Vladimír Čunát | * And we would be breaking people who referenced the removed/stopped jobsets on Hydra. (e.g. with the recent renaming, Hydra is still providing http redirects, but we wouldn't get that here) | 11:54:40 |
| emily | I was thinking just leaving that as-is. it doesn't seem to be a big problem for nixpkgs-unstable(?)
(Darwin stuff blocking the bump because of failures can be)
| 11:55:30 |
| emily | or I'd at least hope it won't be a problem by 26.11 | 11:55:49 |
| emily | if I have to start telling people an even more complicated story about when the channel bumps I'll go nuts :) | 11:56:44 |
| Vladimír Čunát | I'm not fond of making nixos-unstable dependent on darwin builds. | 11:56:45 |
| emily | regardless of success/fail blocking, because of the infra capacity problems? I know there's been issues with -next recently, has it held back nixpkgs-unstable bumps though? | 11:58:04 |
| Vladimír Čunát | I could certainly come with some scenarios, e.g. some security rebuilds do get way more expensive for darwin than linux. | 11:58:06 |
| emily | those should be conditionalized anyway right? | 11:58:35 |
| emily | because nixpkgs-unstable is used on Linux too | 11:58:42 |
| emily | e.g. by all users on other distros by default | 11:58:50 |
| emily | so status quo doesn't change there | 11:59:06 |
| Vladimír Čunát | Flakes also default to nixpkgs-unstable, IIRC. | 11:59:17 |
| emily | yeah, and the channel in the installers I believe | 11:59:36 |
| Vladimír Čunát | But users can easily override this. Verification of blocker NixOS tests does have benefits. | 12:09:30 |
| emily | right. well I was thinking nixpkgs-unstable should probably just gate on those too | 12:19:58 |
