2022-03-21.md

SWG 2022-03-21

Agenda

• A couple of administrative things:

  • How much editorializing do we want when posting to discourse/haskell-cafe?
  • Can we use a collaborative markdown tool for the agenda/notes in the future?
  • Use Ben’s HedgeDoc in the future

• Update on the GHC.X.hackage haskellfoundation/tech-proposals#27

• Update on GHC tick-tock releases: Sketch proposal here

• Update on (Richard's proposal - Maintainership standards)

• Language/compiler features to help stability

  • deprecation mechanisms · Wiki · Glasgow Haskell Compiler / GHC
  • local warning pragmas · Wiki · Glasgow Haskell Compiler / GHC
  • User defined Type Warnings (#17027) · Issues · Glasgow Haskell Compiler / GHC · GitLab

• API breakage policy [Opaleye's] and creating a curated list of them [e.g. Chris Done's Immutable Publishing Policy]

• GHC 9.4 breaking changes

Notes

Quote from the HF Tech Track proposal process:

Before submitting a HFTP, it is required that you perform necessary preparations:
  - Discuss your idea on the Haskell.org Discourse. Currently, we suggest cross-posting on the Haskell Foundation Slack for higher volume commentary. Create a Discourse topic under the category "Haskell Foundation", that starts with "Pre-HFTP” and briefly describe what you would like to change and why you think it’s a good idea.

  - Proposing your ideas on the Discourse is not an optional step. For every change to the ecosystem, it is important to engage in due diligence with the community and relevant stakeholders. Use this step to promote your idea and gather early feedback on your Pre-HFTP proposal. It may happen that experts and community members may have tried something similar in the past and may offer valuable advice."

Maybe posting a Tech Track proposal plus a post to Discourse to invite people to contribute? Something to invite the TT group to consider.

• GHC.X.Hackage update.

  • Ben put a summary of the GHC.X.Hackage proposal to discourse here.
  • He will post on Reddit too, and talk to Gershom.
  • Holding the token: Ben

• GHC tick-tock releases.

  • Post this to discourse
  • Holding the token: Ben

• Maintainership standards.

  • Richard doesn't have time to shepherd this.
  • Nice to have, but not urgent
  • Park this for now, pending (a) getting GHC.X.hackage, and tick-tock releases resolved, and/or (b) an enthusiast to drive it.

• Language features to support migration (deprecations etc)

  • E.g.
    • deprecation mechanisms
    • local warning pragmas
    • User defined Type Warnings
  • Develop a concise list of possible extra language support mechanisms, including examples of when these might be useful
  • Evaluate them in terms of past "bumps in the road"
  • Create a survey for the community and invite feedback about which would be most helpful.
  • Question: do we want to start a workstream to consider what extra language support for deprecations would be helpful? Answer: yes if anyone wants to lead/drive it, perhaps starting from here.
  • GHC experts (notably Ben) happy to fill in any GHC-specific details .
  • Holding the token: Trevis

• API breakage policy.

  • Tom sent arounds Opaleye’s API breakage policy
  • Descriptive vs prescriptive is a benefit
  • GHC might want to have a more explicit breakage policy too
    • And for the next release, breaking changes could be given a rationale; and mitigation strategies.
  • Should we collect a list of these policies for reference?
  • Holding the token: Tom

• GHC 9.4 breaking changes

  • If one wanted to drive a change to not be breaking how would one do that?
    • Open a GHC issue