| 18 Apr 2025 |
 emily | the 23rd is the nominal breaking change deadline and I assume there are breaking changes here | 16:10:40 |
| emily | I think landing in staging by then should be fine, but also: if -next hasn't started yet by then, then merging to staging after that feels fine too (because after all we would triage issues at the same time anyway) | 16:11:22 |
| emily | I don't know what the status of -next is | 16:11:46 |
| emily | I think we're waiting for channel bumps for the Perl security fix first. | 16:12:00 |
| emily | (but maybe ask leona-ya for her interpretation and an exception if it looks like you'll miss it) | 16:12:24 |
 maralorn | Well, the release schedule says -04-29 merge staging-next, but it doesn’t say when that staging-next gets created. However there will start a second staging-next cycle on -05-08 so we are pretty save. The restriction on breaking changes is the bigger problem. | 16:15:09 |
| maralorn | Or, it’s not a problem actually. But it sets our timeline. | 16:15:26 |
| maralorn | Although it’s kinda a very strict rule for us because I think that merging haskell-updates rarely breaks anything but if we believe pvp it is certainly almost every time breaking something. | 16:17:13 |
| maralorn | Anywey. If we take the timeline at face value we have to merge within 5 days. Which is wild considering that our branch got created shortly after the last release … | 16:18:34 |
 sterni | In reply to @maralorn:maralorn.de
That feels wrong to me. If it is relevant it should have a maintainer. How do you find "relevant" packages? vibes revdeps | 16:27:44 |
| sterni | idk, I’m the haskell maintainer am i not | 16:27:55 |
| maralorn | 😆 | 16:30:32 |
| emily | remaining failures can surely be addressed during -next or after it hits master? | 16:30:54 |
| emily | we do have ZHF coming up | 16:31:01 |
| emily | most things going into staging have a lot less testing | 16:31:30 |
| emily | the dates for -next getting merged are fake and I don't know why they're even there | 16:31:49 |
| emily | I mean they're broad targets, but staging-next merge times are probably the last predictable variable in Nixpkgs | 16:32:00 |
| maralorn | Well, that is not how we normally operate. Especially since we mark everything broken before we merge. | 16:32:14 |
| emily | I expect the final breaking -next will start once https://hydra.nixos.org/queue-summary is not churning through a 24.11 world rebuild for Darwin | 16:32:40 |
| emily | well, it's not too surprising that the normal procedure that is a bit out of sync with usual Nixpkgs practice is also out of sync with the release schedule IMO :P | 16:33:20 |
| maralorn | I am not aware of any problems with how we do it. To me doing all QA for our stuff on one branch feels simple. I think it’s feasible because our ecosystem is largely decoupled from the rest. | 16:35:11 |
| emily | I was thinking of e.g. the previous state wrt rebuilds and merging into master | 16:35:50 |
