Infrastructure for tracking upcoming breaking changes

[TeofilC]

I think very often our community is limited by capacity. This motivates a lot of our recent emphasis on stability -- we want to reduce the work required for people to upgrade to new versions of GHC.

Yet, I've also noticed a pattern when GHC versions are released. Initially only a small set of very active maintainers/contributors release compatibility patches. Little happens until the first Stackage nightly is released that is compatible with the new version of GHC. Then a flurry of activity follows.

This suggests to me that at least some people in the community aren't capacity bound but either unwilling to put in effort until they feel like GHC is considered stable enough, or information bound, ie, they are unaware of what work needs to happen.

I think, as it stands, Stackage is our best source of information about what work needs to happen to upgrade to a new GHC. The alternative is to try to build your own projects and see what fails to compile.

So, I'm thinking if we can expand this sort of infrastructure to communicate sooner what sort of work needs to happen for a new release of GHC, then there will be people willing to put in the work.

Stackage currently mostly just handles version bumps (although not exclusively). But I could imagine some infrastructure that collected information about deprecation warnings and tracked which packages had to still be updated (before the warning became an error).

Indeed on the recent CLC discussion about removing mappend/pure, multiple people have expressed that they would be happy to help update the ecosystem. Yet, the warnings hadn't been handled in 10 years in many cases. My feeling is that if we had set up a tracker for which packages needed to be patched when we first added the warnings, all the packages would be patched by now.

I'm not sure what this infrastructure for tracking upcoming breaking changes would look like, perhaps something similar to how the Stackage tracker currently operates. Perhaps we could expand the existing Stackage tracker to track things like this (backed by lots of automation).

I could also see this being tracked as part of an extended head.hackage of some sort.

[hasufell]

CC @juhp

[juhp]

Stackage currently mostly just handles version bumps (although not exclusively).

(I would add that the Stackage project is also a major reporter of build failures actually (even for testsuites), but it is purely a manual process alas and I am not here to argue :-)

But I could imagine some infrastructure that collected information about deprecation warnings and tracked which packages had to still be updated (before the warning became an error).

I would like to see Stackage build logs "exposed" somehow, but we haven't thought seriously about it and it would be some work indeed... specially to do so in a useful way. Another question might be how long we could cache such results.

cc @chreekat

[TeofilC]

(I would add that the Stackage project is also a major reporter of build failures actually (even for testsuites), but it is purely a manual process alas and I am not here to argue :-)

Thanks for clarifying! And as we were saying on the GHC matrix recently automating these things is one good step.

I also liked the stackage experimental idea you mentioned on Discourse. I think that would help a lot with the issues I've outlined here.

As a general point, I feel like there's a lot of potential for resource sharing between what I would like head.hackage to ideally be, stackage and potentially the nixpkgs haskell package set too.

So if we created some new automation to read build logs, figure out the root cause and create issues upstream, it would be nice if it was compatible with as many of those as possible.

[chreekat]

I think this would be a cool topic for Zurihac!