| 22 Jun 2026 |
 Grimmauld (any/all) | I meant killing the all-drivers tests (https://github.com/NixOS/nixpkgs/pull/532396) | 13:45:42 |
 Vladimír Čunát | Yes, I know, but I don't expect it helped dramatically with building all those etc and disk-image derivations. | 13:46:32 |
 K900 | Emily wanted to do it in the jobset unification PR | 13:46:49 |
| Vladimír Čunát | Because these drivers still do get run. | 13:46:50 |
 hexa | we don't understand the impact of container tests yet, do we? | 13:46:54 |
 emily | have local WIP with jobset merge | 14:35:03 |
| emily | so still with x86_64-darwin drop but avoiding any mass rebuilds in the process? I can split up my branch a little for that | 14:37:58 |
| emily | I'm a bit confused by the purported upper bound on the rebuilds though | 14:38:28 |
| emily | the PR has rebuild Darwin stdenv label | 14:38:32 |
| K900 | Scratch that, we don't have enough pnpm for this to need staging | 14:41:05 |
| hexa | okay, master | 14:42:00 |
| hexa | Redacted or Malformed Event | 14:42:12 |
| Vladimír Čunát | Probably, but it's mainly up to you. | 14:45:02 |
| Vladimír Čunát | That's because the CI takes an "incorrect" comparison base. | 14:45:21 |
| Vladimír Čunát | We'll be reusing 26.05 builds, not unstable/master builds | 14:45:33 |
| emily | ah, makes sense. it's almost master sized then, right? as in, it's a number of rebuilds we might have in flight from a few unfortunately large-rebuild master bumps in a row | 14:49:55 |
| emily | (I agree w/ ^ but to be fair dropping a platform will make the numbers on that hard to compare anyway) | 14:50:42 |
| K900 | I mostly care about Linux numbers tbh | 14:50:58 |
| emily | but the thing you're measuring based on, the queue resource, is shared between the platforms | 14:57:42 |
| emily | so fewer Darwin jobs is a confounder | 14:57:51 |
| emily | would you intend for 26.05 or 26.11 to be the next one after this finishes? | 15:36:44 |
| Vladimír Čunát | 26.11 probably. | 16:19:53 |
| emily | makes sense. how about we run this one as-is ~immediately (because we've mostly already built the x86_64-darwin binaries for it because of 26.05), and we can do the dance for the x86_64-darwin drop into staging in tandem ready to start immediately after? should be able to get the start-of-cycle-blocking ones ready for that today | 16:27:59 |
| emily | FWIW, I would like it if we can fold some non-blocking tests back in over time, but I feel the situation with channel updates and staging cycles has become bad/urgent enough that being fairly bold with things is a good move.
if we end up feeling very good about the speed with which we can ship security fixes and have a bunch of slack Hydra capacity from new queue runner + x86_64-darwin drop + more builders + cutting non-blocker tests + etc., then that's slack we could make judgements about where to most effectively allocate, whether that's by undoing some things or otherwise? (hopefully without spending all of it at once)
| 16:31:23 |
| emily | (and my vague feeling is that a lot of the test builds are probably sufficiently low-utility that we'd need them to get very cheap for them to be a particularly effective way of spending that slack, though I'm not super confident about that – but I feel like "which of the n perennial 'things we could do if we had more Hydra capacity' should we prioritize?" is a good problem to have rather than just staying right inside the bounds of what circumstances compel) | 16:33:11 |
| emily | e.g. if merging the jobsets + reducing tests lets us dial up nixos-unstable eval bump frequency to be more like nixpkgs-unstable that feels like a win that probably dwarfs the value most of the non-blocker tests provide | 16:34:54 |
| Vladimír Čunát | There's still ~12k darwin rebuilds per platform, but that's not so much a difference. | 17:41:36 |
| emily | yeah. but saves me having to disentangle a few mass rebuild commits, and still avoids having to build another x86_64-darwin stdenv | 17:46:43 |
| emily | rebased the core PRs I already had up, and I'll work on getting the immediate "fix stuff that would regress from the drop" things out. Randy Eckenrode: do you want to look over these?
- https://github.com/NixOS/nixpkgs/pull/492105
- https://github.com/NixOS/nixpkgs/pull/492160
- https://github.com/NixOS/nixpkgs/pull/493096
- https://github.com/NixOS/nixpkgs/pull/492189
the first one can land any time, the others will need a bit of a dance to go in sequence to not break CI along the way so I'll self-merge those but want to give a chance to look them over
| 18:04:32 |
| emily | vcunat: (I take it current staging will become the cycle after https://github.com/NixOS/nixpkgs/pull/534248?) | 18:05:56 |
