Meeting URL: https://meet.jit.si/StableHaskellMeetBiWeekly
Previous meeting notes
- Updates on in-progress work
- GHC.X.Hackage
- It would appear that there is some agreement that this is useful outside of the HFTT, do we need to do any more?
- GHC tick-tock releases
- Have we reached out to those active in discussions?
- Update on Language/compiler features to help stability
- GHC warning policy document from last time as discussed previously
- Find industry user groups to help smoke test with ghc preleases from May
- GHC.X.Hackage
- Change Generic1 to associate to the left
-
- Revise proposal to address misconceptions squarely.
- Identify problem: libraries are not updated for over a year after release -- reason: 40-deep dependency chains mean that there is a multi-month latency even if every developer responds quickly (an implausible assumption)
- Authors are understandably reluctant to make releases before a GHC is actually released. So that multi-month clock only starts ticking after GHC is actually released.
- Our goal: make it easy for everyone (developers, users, everyone) to (a) contribute library patches, and (b) access all the patches that others have contributed
- Problem is not "coming up with the patch"; it's "making the patch easily available"
- Proposal may address the needs of a silent majority
- Hackage release process remains sequential.
- If we had GHC.X.Hackage, then task X would be faster/easier.
- David C says: People today make progress by pointing their stack/cabal to a hand-rolled set of patches (i.e each is a pointer to a particular commit, maybe not merged yet, in the package's Git repo). This is massively duplicative... everyone does this separately. We want to share this work.
- Give a worked example: an author with many dependencies can use GHC.X.Hackage can fix their package now.
- It would be great to have a progress tracker that showed what libraries are next in the queue to be updated on Hackage, and send maintainers email to tell them.
- Second draft: David
-
- Holding the token to reach out more: Ben
- Why not release annually instead?
- Pressure for last-minute inclusions
- Difficulty for release managers
- Correctness issues for huge releases (though somewhat mitigated by head.hackage these days)
-
Update on Language/compiler features to help stability
- Holding the token: Trevis
-
GHC warning policy document from last time as discussed previously
-
Find industry user groups to help smoke test with ghc preleases from May
- Holding the token: David
-
Change Generic1 to associate to the left
- GHC.X.Hackage and generalizations can help support doing the breakage analysis