| 22 Jun 2026 |
 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 |
 vcunat | 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 |
| vcunat | 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 |
| vcunat | Yes. | 18:12:17 |
| vcunat | Unless something unexpected happens. | 18:12:38 |
 Alyssa Ross | This idea makes sense to me. | 18:13:06 |
| emily | should we merge this into staging first then? I guess it'll ride the train back from -next regardless | 18:18:32 |
| emily | I guess it'd need double cherry-picking if we did that, so never mind :) | 18:20:59 |
| vcunat | Sound good in principle | 18:21:14 |
| emily | (by "this" I meant the -next, but I'm just going to rebase stuff on the merge of current staging + that proposed -next to avoid any conflicts) | 18:22:18 |
 Randy Eckenrode | Left an approval on the first, second is merged already, asked questions on the third, and added yet another approval to the fourth. | 23:51:53 |
| Randy Eckenrode | So, to understand, the next staging-next is just staging-next-26.05 but for unstable? The current staging branch won’t get built until the next cycle? | 23:52:36 |
| emily | replied :) | 23:55:01 |
| emily | AIUI yes except it's not actually staging-next yet. | 23:55:10 |
| emily | (but "next cycle" might be in ~a week, luck permitting?) | 23:55:19 |
| 23 Jun 2026 |
| Randy Eckenrode | I wish we could make aarch64-darwin tier 2. It feels bad deleting x86_64-darwin from tier 2 while leaving it as tier 3. | 00:35:04 |
| Randy Eckenrode | I know tiers are kind of not really a thing anymore, but it’d still be nice. | 00:36:56 |
| emily | https://nixos.org/manual/nixpkgs/unstable/#sec-platform-breakdown says tier 2 | 00:46:12 |
