GHCs dependencies (libraries) and maintenance

[Moritz Angermann]

Hi there!

so this comes up periodically, and I think we need to discuss this.  This is not
related to anything right now, so if you wonder if I'm writing this because of
something that just happened that I'm involved and you might have missed
something, you probably did not.  It came up on the #ghc IRC channel a
few day ago.

GHC depends on quite a set of libraries, and ships those in releases. When ever
a new GHC release is cut, all these dependencies need to be on hackage and
have release versions.  We do not want to produce a GHC release which depends
on in-flight packages.  In-flight might happen for example due to GHC having to
patch dependencies to make them work with HEAD.

Everyone who maintains any kind of software online, knows that maintenance can
be a drag, and then life happens, and what not.  There are many very responsive
maintainers and we all owe them a grate amount of gratitude towards their
relentless work, keeping those libraries up to date and responding to questions,
patches, ...

I therefore would like to float the following idea to make the GHC
release processes
a bit more reliable.  GHCHQ (that is those in charge of producing GHC
releases for
us all), are made co-maintainers on each library GHC depends on, to guarantee
that GHC can move forward in the worst of circumstances.  Now I would
hope that in
almost all cases GHCHQ would never have to maintain any of the dependencies
actively, they deal with GHC already, so let's try to keep it that
way.  However GHCHQ
can, after a 14day notification period, exercise the co-maintainance
and cut releases
(and upload them to hackage), should the maintainer not be able to do
so on his own
for various reasons.

I'd like to see this as an insurance policy for GHC continuous
development.  The only
alternative that I see would be that GHCHQ starts forking dependencies
and initiates
the hackage maintainer takeover protocol, which will cause additional
delays, and
incurs an extra burden on the GHC maintainers.

I hope we can all agree that libraries that end up being dependencies
of GHC should
be held in high regards and form the very foundation GHC is built
upon.  As such it
should be an honour to have GHCHQ being a co-maintainer for ones library, as it
signifies that importances of the library for the continuous development of GHC.

Again I don't expect much to change, except for GHCHQ becoming co-maintainers
for libraries GHC depends on. The baseline expectation will remain as
it is.  However we
will have ensured the frictionless development of GHC going forward.

Cheers,
 Moritz