Looking for a parsec maintainer to assist with GHC 9.14 compatibility (is this package still actively maintained?)

hasufell:

This looks like an error in the GHC release process.
@wz1000 bumped this in the GHC submodules.

Thanks for the pointer @hasufell.

It does seem that GHC’s GitLab mirror of parsec has the following two commits:

branch ghc-9.14 with commit 552730e2 (bump base to <4.23)
branch ghc-10.0 with commit 15f8a710 (bump base to <4.24)

AFAICT neither of these branches (or commits) exists in the canonical repository on GitHub.

Since the canonical repository is what’s referenced by the Hackage version, it seems like the process expects these changes to be propagated back at release time, and that this step was missed for GHC 9.14.1. Is that right?

If so, perhaps this part of the process could be revised? The repository is described as a “mirror”, but GHC-specific commits are being made directly to it, creating two diverging sources of truth. The ghc-10.0 branch suggests the same issue is lined up to recur with GHC 10.0.

I wonder if it’s feasible to instead propagate changes in the following order:

First, to the canonical source repository (currently on GitHub);
then to Hackage;
and finally to the GHC GitLab mirror.

Or alternatively, perhaps the GitLab version could be blessed as the source of truth (reflected in the Hackage package description), and the GitHub version treated as a mirror?

(I appreciate there may be constraints I’m not aware of, and I’d be curious to hear from anyone who knows more about how this process works in practice.)