I joined the Haskell Stability Working Group about a year ago. I was freshly scarred from a GHC upgrade, so I decided to try improving the situation. I think my first contribution was making an example for GHC nightly builds on GitHub Actions. This allows downstream¹ maintainers to build GHC nightly to spot issues early.²

Recently, we’ve been curious about what Haskell ecosystem and GHC changes cause the most breakage. A suggestion was made to do a quantitative analysis of “head.hackage”. “head.hackage” is a repository of patches for Hackage. GHC engineers use these to test out new GHC builds on a wide range of Hackage packages without having to upstream³ a patch, which can take time. Instead, they can put the patch in “head.hackage” and immediately test it on a wide range of packages. We can analyze this repository of patches and categorize them according to the GHC Stability State of Play I volunteered for that effort. Here is a preliminary result of the “head.hackage” patches required to make around 485 packages⁴ build.

From this, we can see that we’re not doing too bad for stability in GHC directly. Many of these patches are for older changes for example. Although, from first hand experience, I know we can definitely improve! We’re going to extend this work by labeling the exact cause of breakage for each patch (many do overlap). This will allow us to see more clearly which changes caused most issues and help us prevent similar situations in the future.

Do you have any opinions on this document? do you feel stability could be better? or do you have a specific frustration which grinds your gears around stability? Please reach out! We’re always interested in hearing from the community and are in fact actively recruiting members. You don’t need to join; you can also email or use the comment box below.