Haskell Foundation Technical Task Force (Slot 2) Meeting
12 March 2021
Present:
Emily Pillmore
Andrew Boardman
Théophile Choutri
Andrew Lelechenko
Edward Kmett
Chris Dornan
Richard Eisenberg
Notes from Previous Meeting:
Tech Agenda Track: Meeting Minutes 3/10
We will work in two different groups, given our availability and time zone differences, using Slack for asynchronous coordination.
Performance Dashboards
-
Why don’t we have something like this?
- We do! It’s http://hackage.haskell.org/package/gipeda
-
Hosted at https://perf.haskell.org/ghc/ in the basement of bryn-mawr
-
Exists in GHC now, but has no nice consumable front end
- How do we gamify this?
-
Who will own it?
some questions about how to expand this beyond core packages:
- how do we know that the methodology of external libraries is sound? e.g. that they don’t run benchmarks on the cloud.
- To avoid problems, we may want to run all the tests on our own box
- should this be open to all of Haskell? perhaps, but only by application. and not for now; let’s gain
- experience first
Ben & Davean to lead in fleshing this out.
Performance Book
- Hecate has blessed Michael’s proposal, and will act as the face
- Some discussion of the approval process for this proposal (see: https://docs.google.com/document/d/1n6lQKSU6t6dd6FAIhxjdNtHfWfEYFSYWasgLvaf0dhc/edit?usp=sharing)
- perhaps wait a week; need to flesh out technical details (how will the book be presented? how will volunteers step up?)
- Needs a project manager
GHC Cadence Discussion
- Backporting is costly and difficult to manage, testing is hard
- Ben is the mechanism, will not decide on this.
- Testing is not the problem - longstanding issues are finally surfacing (e.g. ARM)
- Windows support is struggling in recent releases
- How do we decide what time frame is best?
- Question: who feels the pain from minor releases? is it GHC or users? (maintainers?)
- Andrew:
- if we have fewer releases of GHC, we could have more backports, and we would not need as many major releases.
- Pain within GHC is about # of patches, not really # of releases
- Pain for users is around changes in
base
andtemplate-haskell
We need data:
- How do we collect data about what breaks from version to version?
- Set up a separate issue tracker for collecting “this broke” comments.
- Opt-in automatic metrics phone home
- Would need to get detailed about what data was being collected, and make that publicly available
Migration path:
With tools like retrie and hlint, we are able to give better indications to our users when a release breaks something that we can catch with one of those tools.
UTF-8 Text
- Everything is in order to do the thing, a proposal will be written next week.
- 3 industry partners so far are +1 on the idea, and we’ll speak with more to develop a better impact assessment, but 3/3 so far is a good indicator.