| 3 Jul 2026 |
 vcunat | * I could start a parallel staging-next-26.05, though. There's still more darwin in there. | 15:03:42 |
| vcunat | (and much less human work surely) | 15:03:57 |
| vcunat | Or we could roll the darwin rebuild (or possibly whole staging). | 15:04:34 |
 emily | I can get fixes up for the big blockers | 15:05:07 |
| emily | in like 30-60 minutes | 15:05:20 |
| vcunat | Or that. | 15:05:24 |
| vcunat | Sounds optimal. | 15:05:27 |
| emily | (I wonder if we can conceivably start running staging cycles simultaneously though…) | 15:05:52 |
| vcunat | I don't see a real issue. | 15:06:10 |
| vcunat | Though I don't have much experience with the new queue-runner. | 15:06:29 |
| emily | like as standard – that would be nice in some ways wrt benefiting from the increased efficiency while not compressing the timeline for human reaction for regressions as much | 15:06:34 |
| vcunat | Details around priorities, bumping, etc. | 15:06:39 |
| emily | and also avoid the "do we want unstable or stable users to get this CVSS 10 fix first" thing | 15:06:48 |
| emily | (admittedly by compromising by slowing both of them down vs. if we just picked one) | 15:07:00 |
 hexa | and also … we lack people looking at staging-next | 15:07:49 |
| vcunat | matplotlib by itself hides over 13k jobs right now. | 15:07:31 |
| vcunat | * matplotlib by itself blocks over 13k jobs right now. | 15:07:41 |
| emily | yeah. and most of those will be Python so not even involve linking at all | 15:07:49 |
| hexa | do we want simultatenous lack of people looking at staging-next-26.05? :D | 15:07:58 |
| emily | so I'd expect they should mostly succeed | 15:07:58 |
| vcunat | * matplotlib by itself blocks over 13k jobs right now. (though they would be cheaper on average probably) | 15:08:00 |
| emily | stable -next at least much more rarely regresses, right? | 15:08:17 |
| emily | and when it does the regressions are usually ones that also happen on -next | 15:08:22 |
| hexa | certainly much less, but the first staging-next-26.05 was annoying | 15:08:44 |
| emily | so the human burden of combining them seems comparatively minor, you instead get effectively more human time to handle a comparably large set of regressions | 15:08:53 |
| emily | vs. "the builds are faster than we can fix the issues, so Hydra ends up wasting idle time" | 15:09:07 |
| vcunat | Load-balancing between machine and human time - that's how I thought about it. | 15:10:03 |
| emily | I do think it'd be nice to do one 26.05 and one 26.11 "normally" after this cycle though | 15:13:42 |
| emily | just to get a baseline reference for how fast we can go | 15:13:49 |
| emily | (assuming the next cycle is less dumb than this one) | 15:13:53 |
