| 22 Sep 2025 |
 maralorn | Is that unreasonable? | 12:15:35 |
 sterni | I think it makes sense to stage a bunch of set rebuilding changes on the branch and use a time when the x86_64-linux queue has calmed down a bit to get through it | 12:24:16 |
| sterni | 24.11 rebuilds everything again | 12:24:21 |
 Wolfgang Walther | Imho, yes. That's essentially just making the next cycle much longer. | 12:24:21 |
| sterni | package set update seems to eval already at https://github.com/NixOS/nixpkgs/pull/445051 | 12:26:38 |
| maralorn | I mean ideally the next cycles will be very quick, anyway. | 12:26:55 |
| maralorn | Well, I mean anything that we want to do we can obviously do on the branch. I was just thinking that it might not be necessary to do the cherry-picks. | 12:28:36 |
| maralorn | * Well, I mean anything that we want to do we can obviously do on the branch. No need to stop working. I was just thinking that it might not be necessary to do the cherry-picks. | 12:29:03 |
| Wolfgang Walther | I'm just worrying about merge conflicts that we would have to resolve later. By picking the commits now, we can probably avoid most of them. | 12:33:01 |
| Wolfgang Walther | But maybe there won't be too many, if we don't have too many changes in the cycle anyway. | 12:33:21 |
| sterni | I think it does make sense also just to have visibility on those packages as well | 12:34:11 |
| sterni | but may be inconsequential if staging-next is quick… | 12:34:23 |
| maralorn | I mean, tbf. nixpkgs commit history is a mess anyway. So we can probably just do it … | 12:34:58 |
| sterni | https://github.com/NixOS/nixpkgs/pull/443159 can also go into haskell-updates | 12:54:47 |
