| 22 Apr 2025 |
 alexfmpe | * Huh yeah the other doesn't make much sense disregard | 13:26:21 |
 emily | right, I actually first assumed the latter and then realized it must be the former :) | 13:27:21 |
| emily | anyway I guess returning to the actual original point that was raised, I do feel like things are always going to be inherently difficult on some level unless the practices of the Haskell ecosystem itself change. not sure maintainers of packages supporting older and older GHCs is the answer – back in the day I remember it rather painful and it feeling like a relief to be able to rip out an old version, though maybe there's less CPP these days. ideally GHC would make fewer gratuitous breaking changes or at least do them more gracefully… (though again I understand that it's not as bad as it used to be) | 13:29:14 |
 maralorn | We don’t need a lot of back-compat. Maintainers should imo support [Stackage LTS … Stackage Nightly … Hackage Head] | 13:31:15 |
|  Albert Larsan joined the room. | 13:45:27 |
 malteneuss | If you have the time, could you post this idea to https://discourse.haskell.org/t/how-much-effort-does-backwards-compatibility-require-from-library-authors/11584/79 to further the discussion on this possible direction? (will get more credibility/attention coming from you) | 13:49:57 |
| maralorn | Left a short comment. | 14:09:27 |
| maralorn | This is of course in tension with ghcup keeping 9.6 the recommended ghc. | 14:10:14 |
| alexfmpe | don't see a new haskell-updates PR, guess we're focusing on fixing staging for now?
rebased staging into it for now, don't think it counts as breaking, but if we want this for 25.05, best not dump a mass rebuild late in the cycle? | 14:31:05 |
| alexfmpe | essentially this means you can use the js backend in nixpkgs for browser, not only node
I mean, technically you already can, but need to mess with intermediates | 14:32:33 |
 sterni | https://www.stackage.org/diff/lts-23.19/nightly-2025-04-22 looks like it would be a big pain upgrading at the moment with even more patching | 14:32:48 |
| alexfmpe | y'know, I wonder if our ghc-default+0.2 package set ends up out-building nightly | 14:34:52 |
| alexfmpe | just due to our sheer mass of overrides | 14:35:05 |
| alexfmpe | heck, we have reflex-dom and miso building with +0.4, and the former is pretty heavy dependency wise | 14:36:07 |
| alexfmpe | yeah a lot of packages will have older versions, but so many more actually build | 14:38:01 |
| sterni | IMO you can't track nightly really because the quality varies a lot (which makes sense since it is used to prepare LTS which is of relatively consistent quality). Whenever Nightly switches to the next GHC version basically nothing will work. What you can do is anticipate an LTS release by jumping to Nightly, but in principle this should be more painful than just waiting for LTS. | 14:39:04 |
| alexfmpe | makes sense
still, I wonder if there's no way to work closer and have smaller jumps without straight up becoming the source of truth for stackage | 14:40:40 |
| sterni | It is important to highlight that when we were tracking Nightly it was a special moment in the ecosystem where a bunch of huge breaking changes happened coinciding with GHC 8.10 -> 9.0/9.2. Back then there was a long time until Nightly was forked into LTS since they were waiting on some stuff that took a long time to get fixed. | 14:40:41 |
| sterni | Presumably we got around this by patching a lot of stuff since this was also 2021 ish when we did invest a lot of free time, were more people and generally more motivated. | 14:41:23 |
| alexfmpe | * makes sense
still, I wonder if there's no way to work closer to upstream and have smaller jumps without straight up becoming the source of truth for stackage | 14:41:28 |
| sterni | I think the single biggest game changing thing would probably if there were no more core libraries so you could just migrate libs and ghc independently and individually. | 14:42:12 |
| alexfmpe | guess for now best payoff is just streamlining our current process | 14:45:11 |
| alexfmpe | then hopefully convert other clans to use us as source of truth and become maintainers here rather than there | 14:45:52 |
| alexfmpe | * I just think the whole 'actually run tests and patch things if maintainer checks out' is fundamentally inevitable, so we might as well enshrine that approach
EDIT: me wrong. Stackage does run (native) test suites, they just don't patch stuff | 14:49:09 |
 hellwolf | is such a bot considered:
- extract the list of haskell packages that has patchhes in nixpkgs
- goes to repo of these packages and open/maintain one issue to inform the package owner?
| 18:41:15 |
 Alyssa Ross | That sounds like the sort of thing some maintainers would consider to be spam and damage our reputation, at least without a manual approval step but possibly even with. | 18:43:35 |
| hellwolf | Hmm, could be too enthusiastic behaviour indeed. But perhaps a centralised place first, and opt-in for notifications | 18:45:12 |
| sterni | the issue is decidedly not that maintainers don't know about stuff it's more like they don't read their emails or have other things to do | 23:04:25 |
| sterni | another thing I want to add is that these different systems (Stackage, Nixpkgs, Horizon Haskell, head.hackage, …) exist to address different requirements and I think streamlining this is more of a theoretical possibility. I mean why do we package software if Debian has already done it? | 23:08:22 |
| sterni | e.g. Stackage does not need to care if the latest version of pandoc is not in their stackage lts solver. It doesn't matter to them when they have to drop a package many people use because they can just use an older solver with basically no drawbacks etc. | 23:09:30 |
