| 22 Sep 2025 |
 Wolfgang Walther | sterni should we cherry-pick all the fixes we're not making to staging-next into haskell-updates? | 11:44:41 |
| Wolfgang Walther | * sterni should we cherry-pick all the fixes we're now making to staging-next into haskell-updates? | 11:44:47 |
 maralorn | My suggestion would be to pause work on h-u until staging-next is merged? | 11:57:22 |
| Wolfgang Walther | For possibly a full week or more? | 12:09:35 |
| maralorn | Is that unreasonable? | 12:15:35 |
 sterni (he/him) | 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 (he/him) | 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 (he/him) | 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 (he/him) | I think it does make sense also just to have visibility on those packages as well | 12:34:11 |
| sterni (he/him) | but may be inconsequential if staging-next is quick… | 12:34:23 |
