Hello Ben,
I hope to push the threaded RTS by default MR over the line now when the
GHC proposal has been accepted.
Here is the MR: https://gitlab.haskell.org/ghc/ghc/merge_requests/538
It has some unstable test suite failures: they appear only in some
configurations.
Notably, validate-x86_64-linux-deb9-debug fails more than others:
https://gitlab.haskell.org/ulysses4ever/ghc/pipelines/10289
I'd appreciate if someone could take a look and suggest a path forward.
--
Best wishes,
Artem
On Wed, 18 Sep 2019 at 16:08, Ben Gamari
tl;dr. If you have unmerged work that you would like to be in GHC 8.10 please reply to this email and submit it for review in the next couple of weeks.
Hello everyone,
Now that GHC 8.8.1 is behind us it is time that we begin thinking about 8.10. There seems to be broad consensus within the subset of the community that I sampled that we should try to hold to the usual release date near the end of year for 8.10.1. I believe that this is a feasible goal with the caveat that we push the final release back by a couple of weeks in recognition that busy schedules of the holiday season tends to throw unexpected wrenches into the release process.
In particular I would suggest the following concrete schedule:
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
If you have yet-unmerged work that you would like to see in GHC 8.10 please do be in touch and open a merge request ASAP.
One obvious question is how we will avoid the many delays that plagued the 8.8.1 release. Without delving too deep into the specific reasons for these delays, the reasons fell into two buckets:
1. delays due to CI stabilization 2. coordination delays with upstream libraries 3. fallout from MonadFail changes which landed only late in the release cycle
Of these, (1) is largely behind us and (3) will be avoided by ensuring that core libraries changes are landed *before* the branch date.
This leaves consideration (2). The problem of upstream library coordination has always been a tricky one but has grown more acute as our release schedule has accelerated. While no technical solution will eliminate the issue entirely, we believe that decoupling GHC's release schedule from those of its dependencies' is an important mitigation. We will be discussing this with upstream library maintainers in the coming weeks to establish how we can ensure that releases are available well ahead of the GHC 8.10 release, ideally by alpha2.
Cheers,
- Ben _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs