| 18 Apr 2025 |
 maralorn | Okay, good to know. | 15:55:27 |
 sterni (he/him) | i think it'll be either me or malte sitting down and sinking 1-2 days into it probably if we want to do a decent job | 15:55:53 |
| maralorn | Really, why so long? | 15:56:15 |
| sterni (he/him) | there's always annoying stuff | 15:56:29 |
| maralorn | At this point it’s resolving the merge conflict, checking eval, marking broken and hitting merge, right?^^ | 15:56:49 |
| sterni (he/him) | also you always need to factor in compilation times for some things | 15:57:00 |
| maralorn | True | 15:57:07 |
| sterni (he/him) | I mean if you take that approach | 15:57:10 |
| sterni (he/him) | I'd still want to look through the still failing tab, there is probably still a lot of relevant things in there | 15:57:25 |
| sterni (he/him) | though I think given that HLS is done, it's maybe not so bad anymore | 15:57:47 |
| sterni (he/him) | I lost my mind finishing that because you could just not get anything done | 15:57:58 |
 hellwolf | Iteratively, perhaps we could do it in next batch?
I think I could commit to make HLS/Hlint/stylishhaske/etc. for GHC912 always work since I always keep using the latest :D, which I have done so for this batch of PR. | 15:59:56 |
| hellwolf | Maybe there is some transportable snippets of code to the GHC98, too. I haven't had a look. | 16:02:12 |
 emily | it should probably go in next cycle since that's the last one before the freeze | 16:02:34 |
| maralorn | emily: how do you mean? We really want to hit 25.05 with this. Would it be fine to merge to staging rn? When is staging going to staging-next? | 16:03:34 |
| maralorn | Or is staging already to late and we have to merge to staging-next to reach 25.05? | 16:04:14 |
| maralorn | That feels wrong to me. If it is relevant it should have a maintainer. How do you find "relevant" packages? | 16:09:06 |
| emily | yes, of course it should hit 25.05 :) | 16:10:30 |
| 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 (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 |
