| 22 Apr 2025 |
 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 |
| alexfmpe | Then head.hackage and the other half a dozen linuxes distributing haskell packages all share maintenance effort | 11:43:46 |
| alexfmpe | Just derive everything from something sufficiently expressive to tackle the problem | 11:44:04 |
| alexfmpe | That's what I mean by 'becoming stackage' | 11:44:29 |
| maralorn | The question is: Can we modify the stackage process, put another non-nix abstraction layer between nixpkgs and stackage or is it maybe the easiest to maintain it in nixpkgs like we do now? | 11:44:52 |
| alexfmpe | Putting one more weight on the scale: the splitmix situation isn't even detected by nixpkgs right now but it would be if we had wasm cross because then you get to run test suites on the target with wasmtime or whatever | 11:47:28 |
| alexfmpe | Who outside of nix world is even thinking about cross? | 11:48:01 |
| alexfmpe | We are... inevitable | 11:48:09 |
 hellwolf | "few.." ? | 11:49:21 |
| alexfmpe | I think you're right on the mark with the head.hackage idea | 11:53:08 |
| alexfmpe | horizon haskell is literally doing something like that | 11:53:09 |
| alexfmpe | getting stuff building with 9.14 | 11:53:09 |
| alexfmpe | I don't know why they also do their own separate thing on top of nixpkgs | 11:53:10 |
| alexfmpe | short term? as is
now, if we got the stackage manpower onboard to do a 'migration'... | 11:53:56 |
| hellwolf | a combination of "perceived communication overhead", "not-invented-here", or/and "architectural differences"? | 11:54:21 |
| alexfmpe | getting nixpkgs snapshot to be based on a build-plan out of acme-everything-that-matters might help sell the idea to other folks | 11:54:42 |
| alexfmpe | so there might be a bit of mutually recursive chicken-and-egg process | 11:55:13 |
