| 27 Mar 2026 |
 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 |
| emily | I don't see much reason not to since they get fixed reasonably promptly for obvious reasons | 12:20:20 |
| Vladimír Čunát | So no difference between nixos-unstable and nixpkgs-unstable then? | 12:25:27 |
| Vladimír Čunát | (same for the stable pair which is differently split, confusingly) | 12:25:57 |
| Vladimír Čunát | There's some risk from this jobset getting significantly bigger than either. As it is now, performing an eval can stall progress of builds for about 20 minutes, apparently because of dependencies between postgresql transactions. (doing an eval as one huge transaction is tough) | 12:32:30 |
| Vladimír Čunát | But maybe the reduction in overall job count (summed together over jobsets) would even help this aspect. | 12:33:21 |
