Priorities for upcoming GHC releases

Please no.

The quality of the releases don’t have the required level for this approach.

I’d be quitting my work as GHCup maintainer if I had to fix and manage semi-broken bindists every 10 weeks.

GHC HQ does not prioritize distribution quality and I have tried the last 2 years to convince them otherwise:

  • test bindists don’t work well and are not tested (GHC CI setup doesn’t decouple building and testing properly)… so ghcup test is also broken
  • bindist issues are not fixed post-release, so ghcup maintainer have to do it
  • bindist fixes are often not backported, because they may require changes to CI, so ghcup maintainers have to do it (like the missing manpage issue that I’m still fixing manually for every single release pre-9.10)
  • the build system has to be considered an end user interface
  • there is no proper release communication… not with CLC, not with core library maintainers, not with ghcup maintainers

I am done having these discussions. Whatever I bring up is seen as an isolated bug… but sometimes bugs are a manifestation of:

  • priorities
  • communication style
  • processes

Release engineering has to answer the question: what invariants do we want to maintain?

I don’t think anyone can answer this question right now regarding GHC. I’m sure someone will bring up:

  • lack of funding
  • just become a contributor

No, I think the priorities need to change.

9 Likes