GHCs dependencies (libraries) and maintenance
ben at well-typed.com
Mon Jun 1 15:57:14 UTC 2020
Oleg Grenrus <oleg.grenrus at iki.fi> writes:
> 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 frankly have never liked the term GHC HQ for this reason and generally
avoid using it. I would guess that in the context of Moritz's proposal
it means "the GHC release manager", which is currently me.
> 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?
If this is what it would take I would be happy to perform such
one-on-one handshakes. However, I will say that most maintainers
(thankfully) are very responsive under the current scheme. There are
only a few which have extremely variable communications latencies,
despite many attempts at reaching them. I'm skeptical that adding more
attempts will somehow change this situation.
> 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
> 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
Frankly, the text issue was urgent well before February. I made several
attempts over weeks to get in touch with Herbert to no avail. It
was only in February when it was essentially the *only*
That being said, I will say that there should have been more
communication about the state of the release when the initial release
date came and went. 8.10.1-rc1 was cut two weeks after the scheduled
release date; at this point I expected to be a week or so away from
final. However, it then took months to get releases for a few
submodules. All of this should have been clearly communicated.
> 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?
Yes, we are. This is precisely why I am trying to start this process
earlier. I currently have the base version bump underway (!3335) and am
working on hammering out some remaining Windows issues so we can have a
stable fork point.
However, in general the problem is that it is incredibly hard to know
whether we are *actually* on track schedule-wise when something as small
as a bounds bump may take weeks or months to be merged.
> 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.
I would be happy to send bi-weekly release engineering updates if this
would help upstreams better understand where we are in the release
> And this is one of reasons why I opened an issue about "Annual release
> cycle, its structure and long-term-support".
I have had an editor with my draft response open for the last week.
Apologies that it has taken so long to finish but things have been busy
over the last week due to the imminent fork.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: not available
More information about the ghc-devs