GHCs dependencies (libraries) and maintenance

[Oleg Grenrus]

I want to ask a honest question: Who is GHC HQ? There is a page listing 
who is on

- Haskell.org committee,
- on core libraries committee (CLC),
- GHC steering committee;
- there is a list of named maintainers for core libraries,
- and it is relatively easily to deduce who maintains other tools and 
libraries relevant to GHC (e.g. Cabal or say `shake` for hadrian).

But who are in GHC HQ? Neither google nor gitlab.haskell.org search give 
any hints.
---

I think the core issue here is bad or insufficient communication. 
GHC-8.12 beta release is planned to happen in three months. There are 
patches still in flight (e.g. for process, Cabal has tracking issue 
open). I'm sure that maintainers are able to ack on that. Maybe start by 
requiring these explicit acknowledgments?

I also want to remind about first GHC-8.10 schedule posted on this list

     October  18 2019:  start of one week freeze in preparation for 
branching
     October  25 2019:  ghc-8.10 branch cut
     November 8  2019:  8.10.1-alpha1
     November 22 2019:  8.10.1-alpha2
     December 6  2019:  8.10.1-alpha3
     December 20 2019:  8.10.1-rc1
     January  10 2020:  Final 8.10.1 release

I haven't seen *any* updates to that. GHC-8.10.1 was released in end of 
March 2020, *three months later*, text issue was urgent in beginning of 
February.
The plan for GHC-8.12 is to

  * Mid-June 2020: Aim to have all major features in the tree
  * Late-June 2020: Cut the ghc-8.12 branch
  * June - August 2020: 3 alpha releases
  * 1 September 2020: beta release
  * 25 September 2020: Final 8.12.1 release

are we still on track?

What I'm trying to say, it is that it is hard to believe that issue is 
urgent for GHC. It's not the first time (relating to ghc-8.10) when 
schedules are not been kept.
And this is one of reasons why I opened an issue about "Annual release 
cycle, its structure and long-term-support".

- Oleg

On 1.6.2020 12.23, 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