GHCs dependencies (libraries) and maintenance

[John Ericson]

I completely agree. I would like GHC be able to use *more* of the 
ecosystem than it does today, and there's no way we can can do that 
unless we dramatically decrease the pain per dependency.

John

On 6/1/20 5:23 AM, Moritz Angermann wrote:
> 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
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs