| 22 Apr 2025 |
 alexfmpe | We're all tackling the same problem | 11:25:53 |
| alexfmpe | Well stackage isn't an overlay per se | 11:26:34 |
 maralorn | Problem is that it is kinda fishy to maintain a community wide patchset which is overriding the package authors. That has a very complicated trust model. | 11:27:45 |
| alexfmpe | In reply to @alexfmpe:matrix.org
Well stackage isn't an overlay per se But it's not an orthogonal layer we can just be agnostic to. If they have some package deep in the dependency chains that is broke but only the tests expose it, stackage will happily base other package versions around it and then we need to undo a part of that | 11:28:47 |
| alexfmpe | In reply to @maralorn:maralorn.de
Problem is that it is kinda fishy to maintain a community wide patchset which is overriding the package authors. That has a very complicated trust model. That's true but | 11:29:32 |
| alexfmpe | How does anyone but the package authors prevent the need of after the fact fixups? | 11:30:50 |
| alexfmpe | What I think we can do is be more strict on the whole *nudge upstream when adding overrides* | 11:31:37 |
| alexfmpe | In reply to @alexfmpe:matrix.org
How does anyone but the package authors prevent the need of after the fact fixups? For instance, both js and wasm backends are unusable without overrides if they depend on splitmix | 11:32:38 |
| maralorn | In reply to @alexfmpe:matrix.org
What I think we can do is be more strict on the whole *nudge upstream when adding overrides* Maybe we can automate this better and do it earlier. | 11:32:51 |
| alexfmpe | One of them is a PR since 2023 | 11:32:57 |
 @malteneuss:matrix.org | The head.hackage thing was discussed https://discourse.haskell.org/t/language-library-and-compiler-stability-moved-from-ghc-9-6-migration-guide/5745/92?u=malteneuss, but my impression is that it's a crutch, and not a final solution (see SPJ post afterwards). | 11:33:24 |
| alexfmpe | Maintainer doesn't want to accept the backend specific stuff because they can't check it in CI | 11:33:27 |
| alexfmpe | So it's a deadend | 11:33:37 |
| alexfmpe | In reply to @maralorn:maralorn.de
Maybe we can automate this better and do it earlier. Agreed but it's fundamentally just minimizing the surface area of the sketchy trust model | 11:34:14 |
| maralorn | In reply to @maralorn:maralorn.de
Maybe we can automate this better and do it earlier. Most problems we encounter when switching our LTS could have been detected well in advance. | 11:34:25 |
| alexfmpe | If anything, consolidating efforts with the other overridistans would allow for more eyes to sign iff on the same thing | 11:35:02 |
| alexfmpe | * If anything, consolidating efforts with the other overridistans would allow for more eyes to sign off on the same thing | 11:35:10 |
| alexfmpe | That actually relaxes the trust model | 11:35:18 |
| maralorn | I am guilty of this myself. I often only fix stuff, when it breaks during a nixpkgs update. | 11:35:26 |
| alexfmpe | Imagine 3-out-of-5 approvals needed for merges | 11:35:38 |
| alexfmpe | A la clc proposal | 11:35:44 |
| alexfmpe | As it is we have 1-out-of-2 being done in half a doze different places | 11:36:08 |
| alexfmpe | * As it is we have 1-out-of-2 being done in half a dozen different places | 11:36:14 |
| alexfmpe | In reply to @maralorn:maralorn.de
Most problems we encounter when switching our LTS could have been detected well in advance. It might be less painful to follow nightly really. Then we get smaller steps and follow upstream more closely so we can quickly tell them 'nevermind the bounds, foo is just broken' before they bump 300 other packages assuming that one can be bumped | 11:37:53 |
| alexfmpe | * As it is we have 1-out-of-N being done in half a dozen different places | 11:40:09 |
| maralorn | I mean I see your point. I am just not sure that the whole stackage does a wrong bump problem is what is biting is in practice. | 11:41:18 |
| alexfmpe | In reply to @alexfmpe:matrix.org
For instance, both js and wasm backends are unusable without overrides if they depend on splitmix er, that is, if you try to use packages that depend on splitmix you have a runtime failure as soon as that bit is evaluated | 11:41:22 |
| alexfmpe | Yeah I don't think it's anywhere near the top of our problems | 11:41:59 |
| 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 | 11:43:03 |
| alexfmpe | And make that the source of truth | 11:43:15 |
