From ben at well-typed.com Mon Jan 22 16:00:07 2024 From: ben at well-typed.com (Ben Gamari) Date: Mon, 22 Jan 2024 11:00:07 -0500 Subject: [GHC-Releases] GHC 9.10 release schedule and core library status Message-ID: <87a5ox1hq4.fsf@smart-cactus.org> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From hecate at glitchbra.in Mon Jan 22 17:44:13 2024 From: hecate at glitchbra.in (=?UTF-8?Q?H=C3=A9cate?=) Date: Mon, 22 Jan 2024 18:44:13 +0100 Subject: [GHC-Releases] GHC 9.10 release schedule and core library status In-Reply-To: <87a5ox1hq4.fsf@smart-cactus.org> References: <87a5ox1hq4.fsf@smart-cactus.org> Message-ID: 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 From andrew.lelechenko at gmail.com Mon Jan 22 23:59:02 2024 From: andrew.lelechenko at gmail.com (Andrew Lelechenko) Date: Mon, 22 Jan 2024 23:59:02 +0000 Subject: [GHC-Releases] GHC 9.10 release schedule and core library status In-Reply-To: <87a5ox1hq4.fsf@smart-cactus.org> References: <87a5ox1hq4.fsf@smart-cactus.org> Message-ID: <9F3AC138-DE67-4F17-8BEE-3CC50E24CA35@gmail.com> Thanks, Ben. (I’m not subscribed to mail lists CC’d, so I expect this reply to be missing from them) CC’ng Matthew Craven on behalf of bytestring, Xia Li-yao on behalf of text, Lei Zhu, Carsten König and Miao ZhiCheng on behalf of array (it’s not orphaned). Several blockers from the top of my head: * Bump containers submodule to 0.7, long overdue. AFAIR blocked on https://github.com/judah/haskeline/pull/186 - Ben, are you able to merge it? * Bump filepath submodule to 1.5 and add os-string to boot libraries. Julian might remember better, but AFAIR there are no blockers, just someone has to upgrade several submodules at once. * GHCJS progress depends on merging outstanding PRs for bytestring and text to provide pure Haskell implementations, and I imagine Sylvain (CC’d) would wish them to be merged and released before GHC 9.10 is forked. * Mikolaj, are we looking for Cabal 3.12 or carrying on with 3.10.3+? There are at least two important features missing from Cabal 3.10: semaphores and multiple home units. Best regards, Andrew > On 22 Jan 2024, at 16:00, Ben Gamari wrote: > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikolaj at well-typed.com Tue Jan 23 08:32:19 2024 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Tue, 23 Jan 2024 09:32:19 +0100 Subject: [GHC-Releases] GHC 9.10 release schedule and core library status In-Reply-To: <9F3AC138-DE67-4F17-8BEE-3CC50E24CA35@gmail.com> References: <87a5ox1hq4.fsf@smart-cactus.org> <9F3AC138-DE67-4F17-8BEE-3CC50E24CA35@gmail.com> Message-ID: > * Mikolaj, are we looking for Cabal 3.12 or carrying on with 3.10.3+? There are at least two important features missing from Cabal 3.10: semaphores and multiple home units. We plan to have Cabal 3.12 in time. On Tue, Jan 23, 2024 at 12:59 AM Andrew Lelechenko wrote: > > Thanks, Ben. (I’m not subscribed to mail lists CC’d, so I expect this reply to be missing from them) > > CC’ng Matthew Craven on behalf of bytestring, Xia Li-yao on behalf of text, Lei Zhu, Carsten König and Miao ZhiCheng on behalf of array (it’s not orphaned). > > Several blockers from the top of my head: > > * Bump containers submodule to 0.7, long overdue. AFAIR blocked on https://github.com/judah/haskeline/pull/186 - Ben, are you able to merge it? > > * Bump filepath submodule to 1.5 and add os-string to boot libraries. Julian might remember better, but AFAIR there are no blockers, just someone has to upgrade several submodules at once. > > * GHCJS progress depends on merging outstanding PRs for bytestring and text to provide pure Haskell implementations, and I imagine Sylvain (CC’d) would wish them to be merged and released before GHC 9.10 is forked. > > * Mikolaj, are we looking for Cabal 3.12 or carrying on with 3.10.3+? There are at least two important features missing from Cabal 3.10: semaphores and multiple home units. > > Best regards, > Andrew > > On 22 Jan 2024, at 16:00, Ben Gamari wrote: > > 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 > > From rf at rufflewind.com Tue Jan 23 09:17:05 2024 From: rf at rufflewind.com (Phil Ruffwind) Date: Tue, 23 Jan 2024 01:17:05 -0800 Subject: [GHC-Releases] GHC 9.10 release schedule and core library status In-Reply-To: <87a5ox1hq4.fsf@smart-cactus.org> References: <87a5ox1hq4.fsf@smart-cactus.org> Message-ID: Aiming to release directory-1.3.8.3 by the end of the month to fix https://github.com/haskell/directory/issues/170. On Mon, Jan 22, 2024 at 8:00 AM Ben Gamari wrote: > > 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 From hasufell at posteo.de Sat Jan 27 10:35:37 2024 From: hasufell at posteo.de (Julian Ospald) Date: Sat, 27 Jan 2024 10:35:37 -0000 Subject: [GHC-Releases] GHC 9.10 release schedule and core library status In-Reply-To: References: <87a5ox1hq4.fsf@smart-cactus.org> Message-ID: <6a7d9d6d-7511-9dea-9b96-243e5188caab@posteo.de> 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 >