<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Thanks, Ben. (I’m not subscribed to mail lists CC’d, so I expect this reply to be missing from them)<div><br></div><div>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). </div><div><br></div><div>Several blockers from the top of my head:</div><div><br></div><div>* Bump containers submodule to 0.7, long overdue. AFAIR blocked on <a href="https://github.com/judah/haskeline/pull/186">https://github.com/judah/haskeline/pull/186</a> - Ben, are you able to merge it?</div><div><br></div><div>* 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.</div><div><br></div><div>* 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. </div><div><br></div><div>* 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.</div><div><br></div><div>Best regards,</div><div>Andrew<br><div><br><blockquote type="cite"><div>On 22 Jan 2024, at 16:00, Ben Gamari <ben@well-typed.com> wrote:</div><br class="Apple-interchange-newline"><div><div>Hi all,<br><br>First, apologies for the silence regarding the 9.10 fork; I was hoping<br>to improve our communications with boot library authors in the run-up to<br>GHC 9.10 but illness unfortunately took me largely out of commission for<br>a first few weeks of the year. Happily, things are looking rosier now.<br><br>Having had a chance to look at the 9.10 branch and the release goals, I<br>am planning to cut the fork for GHC 9.10 around a month from today, on<br>23 Februrary 2024. This leaves around a month of time to merge the<br>`ghc-internals` split and a few of the other bits of work that remain<br>outstanding. We anticipate the first alpha release will come a week<br>after the fork (see the Milestone [1] for further details).<br><br>How does this sound to you?<br><br>For organizational purposes, it would be helpful if we designated a<br>coordinating maintainer for each of our boot packagers for the 9.10 release.<br>My understanding is that our boot libraries have the following primary<br>maintainers but don't hesitate to let me know if you believe this to be<br>incorrect:<br><br>| Package | Maintainer |<br>| --------------- | -------------------------- |<br>| Cabal | Mikolaj Konarski |<br>| Win32 | Tamar Christina |<br>| array | (orphaned) |<br>| binary | Lennart Kolmodin? |<br>| bytestring | Andrew Lelechanko |<br>| containers | David Feuer |<br>| deepseq | Melanie Phoenix |<br>| directory | Phil Rufflewind |<br>| exceptions | Ryan Scott |<br>| filepath | Julian Ospald |<br>| haddock | Hecate |<br>| haskeline | Judah Jacobson |<br>| hpc | David Binder |<br>| mtl | Emily Pillmore |<br>| parsec | Oleg Grenrus |<br>| process | Michael Snoyman |<br>| stm | Simon Marlow |<br>| terminfo | Judah Jacobson |<br>| text | Andrew Lelechanko |<br>| time | Ashley Yakeley |<br>| transformers | Ross Paterson |<br>| unix | Julian Ospald |<br><br>It would be great if each maintainer could let me know what they would<br>like to do for the 9.10 release. In general we would love to have the<br>set of boot libraries pinned down at least in version by the second<br>alpha, which we are planning for the second week of March 2024. Does<br>this sound reasonable?<br><br>As always, I would encourage core library maintainers to be conservative<br>in their plans for a GHC release and avoid introducing major features or<br>refactorings in their release. Such changes both add risk to the release<br>schedule and complicate the users' migration paths; consequently, they<br>are ideally best held for releases asynchronous to the GHC release<br>process.<br><br>Thanks again for all of your work!<br><br>Cheers,<br><br>- Ben<br><br><br>[1] https://gitlab.haskell.org/ghc/ghc/-/milestones/380#tab-issues<br></div></div></blockquote></div><br></div></body></html>