| 27 Mar 2026 |
 emily | again I don't propose any change to how channels advance | 11:08:00 |
| emily | I genuinely just mean merging the jobsets themselves | 11:08:15 |
 K900 | Hm | 11:08:52 |
| K900 | We can probably do that fairly easily yeah | 11:08:59 |
| emily | this came up because I wanted to have one Nixpkgs pin that passed both nixos-unstable and nixpkgs-unstable gates which is hard to do manually right now because they're almost never building the same commit | 11:09:03 |
| K900 | Sorry, it's migraine day | 11:09:12 |
| K900 | My brain is very mush | 11:09:26 |
| emily | if they were at least attempting the same commits you'd just pick evals that have both tested jobs passing | 11:09:30 |
 toonn | Could the channel jobsets only contain the respective tests? Both depending on a third jobset that does the actual building of packages? | 11:11:20 |
| K900 | Nope | 11:11:37 |
| K900 | Hydra has no concept of jobset dependencies | 11:11:47 |
| K900 | So it'll just end up evaluating different commits | 11:11:56 |
| emily | it seems like it would take non-trivial load off the queue runner to merge right? | 11:14:50 |
| 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 |
