[Pre-HFTP] GHC.X.hackage: A tool for easing migrations to new GHC versions

I very much like the emphasis on trying to parallelize the care-taking of our library ecosystem!

Cutting down on critical path length, and being blocked by tangential things one isn’t even using, are key objectives I would like to keep in mind not only to motivate this project, but other projects in the future.

My main concern is strictly procedural. This seems like a great idea, but there is no concrete “ask” of the HF. I thus am not sure this is currently eligible to be an HF proposal!

I think it would be good to see GitHub - haskell/ecosystem-proposals: Proposals for the Haskell Ecosystem resurrected for these sorts of things, namely technical plans that are cross-cutting and don’t fall into ghc-proposals or a similar per-project bucket.

If/when the project needs extra funding, a HFTT proposal could be written, but frankly I doubt that is necessary, because as far as I am concerned @bgamari and others are within rights to just decide GHC’s CI needs this / includes a superior head.hackage.

(In fact, I think they could even do that without the “ecosystem proposal” — it is also means to the existing end, and we shouldn’t be micromanaging the “how” ! But it can be still be nice to do the ecosystem proposal to gauge excitement / gauge whether people seem likely to help contribute to so the goal of parallelized / crowd-sourced upkeep is realized.)

2 Likes