| 23 Oct 2024 |
 maralorn | In reply to @emilazy:matrix.org
yep, makes sense. I was thinking nightly would be more rolling-release, but I guess it's more like nightlies are just alpha versions of the next LTS, so you still eat a whole bunch of breakage all at once? Yes, exactly. That is because ghc bundles roughly 30 libraries these days, so at least those don’t get rolling release at all but get always bumped together with ghc. (in stackage, cabal can actually give you more flexibility with that, but stackage is kinda pinned to the bundled versions because of its global consistency requirement) | 11:34:41 |
 emily | jeez, 30? I feel like it used to be more like 10. | 11:35:06 |
 sterni (he/him) | Unfortunately not. The problem is that when nightly is deemed ready and forked into an LTS snapshot, nightly is usually bumped to a new compiler. Then all hell breaks loose because it is only then people realize how broken everything is and a lot of packages get removed and gradually reintroduced when their maintainers manage to catch up. They can sort of afford that because you can just pick a solver that works for you. We, on the other hand, have some kind of quality standard in mind that we have to achieve every haskell-updates merge. | 11:35:22 |
| sterni (he/him) | so tracking nightly would probably mean occasionally jumping ahead of LTS which is probably very work intensive | 11:35:52 |
| sterni (he/him) | maralorn: well and some are properly tied to ghc, e.g. base | 11:36:21 |
| emily | right. I was thinking of nightly as "if it hurts, do it more often", but if it's more just like tracking n + 1 instead of n then it seems like a bad deal, given that you pay for that + 1 in "nothing works" currency. | 11:37:32 |
| sterni (he/him) | Also when we tracked nightly was kind of a special time when aeson 2.0 came out and GHC moved to the 9.* versions. That felt like years of the ecosystem stuck in a strange transition period | 11:37:38 |
| maralorn | I mean I guess at some point in the lifecycle nightly is probably already stable enough for us and at that point we could just jump the gun. And I actually don’t think it would be significantly more work than waiting for it officially becoming LTS. But as I said, we are normally to busy to do that in that moment so we wait until we are forced. | 11:37:43 |
| emily | I don't suppose there's any convenient lining-up with the release cycle where you could e.g. jump to a nightly that will be LTS by the time the Nixpkgs release happens? | 11:38:16 |
| maralorn | Actually it might make sense to do it after the 24.11 release … | 11:39:03 |
| sterni (he/him) | I think stackage releases when it's “ready” or when they really want to move to a new GHC version on nightly or whatever | 11:39:05 |
| sterni (he/him) | I mean jumping to nightly may be worth a try. We'd need to gain experience when the /magic moment/ to jump is probably. | 11:39:37 |
| emily | In reply to @maralorn:maralorn.de
Actually it might make sense to do it after the 24.11 release … it's always nicer to eat pain early in release cycle rather than late at least :) | 11:40:02 |
| maralorn | 34 actually, https://downloads.haskell.org/ghc/latest/docs/users_guide/9.10.1-notes.html#included-libraries | 11:40:11 |
| emily | (FWIW I have no objection to tracking LTS or anything. just looking to learn more about the procedures) | 11:40:50 |
| maralorn | In reply to @sternenseemann:systemli.org
I mean jumping to nightly may be worth a try. We'd need to gain experience when the /magic moment/ to jump is probably. Probably need some kind of canary packages. i.e. pandoc, hledger or something needs to be included. | 11:41:13 |
| maralorn | In reply to @emilazy:matrix.org
(FWIW I have no objection to tracking LTS or anything. just looking to learn more about the procedures) Discussion didn’t feel hostile in the slightest. | 11:41:41 |
| emily | just wanted to be clear that I'm not being like hey you should change something 😅 | 11:43:37 |
| emily | In reply to @maralorn:maralorn.de
Probably need some kind of canary packages. i.e. pandoc, hledger or something needs to be included. a "channel blocker job" of sorts for release-haskell.nix, I suppose? | 11:44:05 |
| sterni (he/him) | what you probably can do is checking the diff (e.g. https://www.stackage.org/diff/lts-22.39/nightly-2024-10-22) and contemplating whether you can afford breaking the packages that have been removed | 11:45:27 |
| maralorn | In reply to @emilazy:matrix.org
just wanted to be clear that I'm not being like hey you should change something 😅 Well it was a nice reminder, that that is actually what we (at least I) want. It’s just that we didn’t get to it. | 11:45:31 |
| sterni (he/him) | but another question are of course untracked packages that may be broken by upgrades that are fine in stackage | 11:45:50 |
| emily | losing amazonka sounds painful (or does nobody use that any more?) | 11:46:21 |
| maralorn | Huh, at some point I didn’t give a shit about amzonka. I don’t work for jeff bezos … But now we use it at work, so I kinda have to care. /o\ | 11:47:18 |
| emily | oh no, lambdabot too. unshippable. | 11:47:29 |
| maralorn | I mean it doesn’t have to mean that we can’t fix them. We are allowed workarounds which stackage doesn’t. | 11:50:16 |
| emily | the lambdabot part was a joke :) | 11:51:48 |
| emily | amazonka and sdl2 seemed like the only worrying things from a quick scan. | 11:51:59 |
| emily | so maybe after 24.11 would be reasonable. | 11:52:15 |
| maralorn | Well, there is also apparently no ghc-lib-parser and thus no ormolu, hlint, hindent and stuff like that. A bit unclear to me whether that’s normal on nightly. | 11:53:03 |
