| 18 Apr 2025 |
 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 (he/him) | 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 (he/him) | 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 |
| emily | (but also just that the freeze schedule is designed around the normal procedures where everything is being batched together) | 16:36:10 |
| emily | anyway, freeze exceptions are not uncommon so it shouldn't be a big issue, but it's not sounding to me like there are remaining issues of the kind that would prevent a merge into staging | 16:36:53 |
| maralorn | Anyway the way I read the release schedule it says "2025-05-08 unrestrict all breaking changes on staging" for me the natural conclusion is: Everything that hits staging before -05-08 will reach the release. | 16:41:08 |
| maralorn | You are. And you are free to fix or maintain any package you want. However your vibes are not actionable for anyone else and if you insist on that mode you are the only one who can approve a merge. So I will do you the favor of ignoring that. Feel free to announce any package you want to have working before the merge at any time though. | 16:45:20 |
| emily | right but we do ideally try to have a cycle without breaking changes | 16:50:19 |
| emily | since even fixes/minor bumps can cause enough headaches | 16:50:33 |
| emily | though of course that can happen after branch-off, but we don't always get as many -next cycles as we'd like | 16:50:53 |
| emily | sometimes all the last-minute breaking changes pile into one cycle and then we need another one to clean up remaining carnage :P | 16:51:14 |
| emily | anyway, since the Haskell stuff has received so much testing I don't anticipate great issues. (but AIUI the cases where Haskell stuff interacts with the rest of the system don't get as much testing, so I do think landing soon would be good) | 16:51:49 |
| emily | (like, maybe a major ShellCheck or Pandoc bump might break stuff. I don't know if those are in the pipeline, just an example of a fire we might have to put out during a -next cycle) | 16:52:15 |
|  petrockette changed their profile picture. | 17:38:09 |
