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 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 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.
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* record. 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 process.
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. Cheers, - Ben