Re: GHC 9.10 release schedule and core library status

Hi Ben! For the 9.10 release I would like to cut the accompanying Haddock release from the GHC tree. Cool features will have to wait for 9.12, so that that the new team can get acquainted with the code base and the bugs. Thank you for reaching out. Cheers, Hécate Le 22/01/2024 à 17:00, Ben Gamari a écrit :
Hi all,
First, apologies for the silence regarding the 9.10 fork; I was hoping to improve our communications with boot library authors in the run-up to GHC 9.10 but illness unfortunately took me largely out of commission for a first few weeks of the year. Happily, things are looking rosier now.
Having had a chance to look at the 9.10 branch and the release goals, I am planning to cut the fork for GHC 9.10 around a month from today, on 23 Februrary 2024. This leaves around a month of time to merge the `ghc-internals` split and a few of the other bits of work that remain outstanding. We anticipate the first alpha release will come a week after the fork (see the Milestone [1] for further details).
How does this sound to you?
For organizational purposes, it would be helpful if we designated a coordinating maintainer for each of our boot packagers for the 9.10 release. My understanding is that our boot libraries have the following primary maintainers but don't hesitate to let me know if you believe this to be incorrect:
| Package | Maintainer | | --------------- | -------------------------- | | Cabal | Mikolaj Konarski | | Win32 | Tamar Christina | | array | (orphaned) | | binary | Lennart Kolmodin? | | bytestring | Andrew Lelechanko | | containers | David Feuer | | deepseq | Melanie Phoenix | | directory | Phil Rufflewind | | exceptions | Ryan Scott | | filepath | Julian Ospald | | haddock | Hecate | | haskeline | Judah Jacobson | | hpc | David Binder | | mtl | Emily Pillmore | | parsec | Oleg Grenrus | | process | Michael Snoyman | | stm | Simon Marlow | | terminfo | Judah Jacobson | | text | Andrew Lelechanko | | time | Ashley Yakeley | | transformers | Ross Paterson | | unix | Julian Ospald |
It would be great if each maintainer could let me know what they would like to do for the 9.10 release. In general we would love to have the set of boot libraries pinned down at least in version by the second alpha, which we are planning for the second week of March 2024. Does this sound reasonable?
As always, I would encourage core library maintainers to be conservative in their plans for a GHC release and avoid introducing major features or refactorings in their release. Such changes both add risk to the release schedule and complicate the users' migration paths; consequently, they are ideally best held for releases asynchronous to the GHC release process.
Thanks again for all of your work!
Cheers,
- Ben
[1] https://gitlab.haskell.org/ghc/ghc/-/milestones/380#tab-issues
-- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

Hi, I'm unsure what the process here is. Do you expect every boot library maintainer to follow GHC issue tracker and comment there? Or to open a PR against ghc repo? I definitely won't do the latter as an unpaid volunteer (I don't want to deal with GHC MRs and CI). For 'filepath' and 'unix' (and 'os-string', which is to become a boot package) I'd prefer if you open issues on each issue tracker. If that is too cumbersome, please link me to the place where I'm supposed to comment and give me a deadline. 'filepath' just had a severe bug fixed that may need to be backported. Thanks, Julian On 1/23/24 01:44, Hécate via Libraries wrote:
Hi Ben!
For the 9.10 release I would like to cut the accompanying Haddock release from the GHC tree.
Cool features will have to wait for 9.12, so that that the new team can get acquainted with the code base and the bugs.
Thank you for reaching out.
Cheers,
Hécate
Le 22/01/2024 à 17:00, Ben Gamari a écrit :
Hi all,
First, apologies for the silence regarding the 9.10 fork; I was hoping to improve our communications with boot library authors in the run-up to GHC 9.10 but illness unfortunately took me largely out of commission for a first few weeks of the year. Happily, things are looking rosier now.
Having had a chance to look at the 9.10 branch and the release goals, I am planning to cut the fork for GHC 9.10 around a month from today, on 23 Februrary 2024. This leaves around a month of time to merge the `ghc-internals` split and a few of the other bits of work that remain outstanding. We anticipate the first alpha release will come a week after the fork (see the Milestone [1] for further details).
How does this sound to you?
For organizational purposes, it would be helpful if we designated a coordinating maintainer for each of our boot packagers for the 9.10 release. My understanding is that our boot libraries have the following primary maintainers but don't hesitate to let me know if you believe this to be incorrect:
| Package | Maintainer | | --------------- | -------------------------- | | Cabal | Mikolaj Konarski | | Win32 | Tamar Christina | | array | (orphaned) | | binary | Lennart Kolmodin? | | bytestring | Andrew Lelechanko | | containers | David Feuer | | deepseq | Melanie Phoenix | | directory | Phil Rufflewind | | exceptions | Ryan Scott | | filepath | Julian Ospald | | haddock | Hecate | | haskeline | Judah Jacobson | | hpc | David Binder | | mtl | Emily Pillmore | | parsec | Oleg Grenrus | | process | Michael Snoyman | | stm | Simon Marlow | | terminfo | Judah Jacobson | | text | Andrew Lelechanko | | time | Ashley Yakeley | | transformers | Ross Paterson | | unix | Julian Ospald |
It would be great if each maintainer could let me know what they would like to do for the 9.10 release. In general we would love to have the set of boot libraries pinned down at least in version by the second alpha, which we are planning for the second week of March 2024. Does this sound reasonable?
As always, I would encourage core library maintainers to be conservative in their plans for a GHC release and avoid introducing major features or refactorings in their release. Such changes both add risk to the release schedule and complicate the users' migration paths; consequently, they are ideally best held for releases asynchronous to the GHC release process.
Thanks again for all of your work!
Cheers,
- Ben
[1] https://gitlab.haskell.org/ghc/ghc/-/milestones/380#tab-issues

Julian Ospald
Hi,
I'm unsure what the process here is. Do you expect every boot library maintainer to follow GHC issue tracker and comment there? Or to open a PR against ghc repo? I definitely won't do the latter as an unpaid volunteer (I don't want to deal with GHC MRs and CI).
We created the `ghc-releases` mailing list for the purpose of release coordination. In the past I have also frequently created tracking tickets in submodules' upstream repositories. I have not done that this time as we have this mailing list but I would be happy to do so if this would be preferable.
For 'filepath' and 'unix' (and 'os-string', which is to become a boot package) I'd prefer if you open issues on each issue tracker. If that is too cumbersome, please link me to the place where I'm supposed to comment and give me a deadline.
Sure, I will create a pair of tracking tickets. The proposed deadline is before the second week in March. Cheers, - Ben

Hi,
Have all core/boot library maintainers been notified to join that mailing list? Where is that information? I don't see it.
The only reason I got wind of this is because Hécate CCed the library ML as well.
I remain unconvinced that this is a good way of coordinating releases across 20+ maintainers.
Information that is necessary:
- what versions do YOU need?
- what versions do maintainers want to see in the next GHC release?
- do maintainers want a "backport" of a version bump to an older GHC branch?
- relationships between core libraries (that is the case for filepath)
- deadline
This could possibly be expressed in a shared spreadsheet, so that everyone understands the current status without going through mailing lists they're not subscribed to or issue trackers with 10+ posts.
Thanks,
Julian
On February 5, 2024 2:28:16 PM UTC, Ben Gamari
Julian Ospald
writes: Hi,
I'm unsure what the process here is. Do you expect every boot library maintainer to follow GHC issue tracker and comment there? Or to open a PR against ghc repo? I definitely won't do the latter as an unpaid volunteer (I don't want to deal with GHC MRs and CI).
We created the `ghc-releases` mailing list for the purpose of release coordination. In the past I have also frequently created tracking tickets in submodules' upstream repositories. I have not done that this time as we have this mailing list but I would be happy to do so if this would be preferable.
For 'filepath' and 'unix' (and 'os-string', which is to become a boot package) I'd prefer if you open issues on each issue tracker. If that is too cumbersome, please link me to the place where I'm supposed to comment and give me a deadline.
Sure, I will create a pair of tracking tickets. The proposed deadline is before the second week in March.
Cheers,
- Ben

Julian Ospald
Hi,
Have all core/boot library maintainers been notified to join that mailing list? Where is that information? I don't see it.
The only reason I got wind of this is because Hécate CCed the library ML as well.
I remain unconvinced that this is a good way of coordinating releases across 20+ maintainers.
Information that is necessary:
- what versions do YOU need? - what versions do maintainers want to see in the next GHC release? - do maintainers want a "backport" of a version bump to an older GHC branch? - relationships between core libraries (that is the case for filepath) - deadline
This could possibly be expressed in a shared spreadsheet, so that everyone understands the current status without going through mailing lists they're not subscribed to or issue trackers with 10+ posts.
That sounds like a fine idea. I would be happy to put together such a spreadsheet if others would find this useful. Cheers, - Ben
participants (3)
-
Ben Gamari
-
Hécate
-
Julian Ospald