| tags |
|---|
swg |
Meeting URL: https://meet.jit.si/StableHaskellMeetBiWeekly
Previous meeting notes
- Trevis Elser
- JMCT
- Ben Gamari
- SPJ
-
Minor edits and encourage discussion on extension classificaiton proposal.
- Bring up at ghc weekly
- Expecting feedback soon.
- Bring up at ghc weekly
-
SWG post for blog.haskell.org
- In progress!
- Holding the token: Trevis
-
hoogle.haskell.org went down.
- Infrastructure stability/availablity is important to community. Can SWG help somehow?
- HF critical infra page
- status.haskell.org?
- Who runs this? If anyone
- Still lists darcs? Is that available?
- Links to https://stats.uptimerobot.com/6YOwyfoV7k which appears broken (is that the same as http://auto-status.haskell.org/?)
- Include how to get in touch with those involved in running/maintaining.
- Holding the token: JMCT
- status.haskell.org?
-
More discussion on GHC releases
-
Some misunderstandings here?
- Perhaps a feeling among non-GHC devs that GHC team prioritises agility and experimentation over stability.
- Feedback cycles not matching release cycles.
- E.g. industrial users are on a lagging cycle and/or cannot be current until certain issues are fixed
- More frequent releases may actually help stability, by highlighting failures earlier, when they can more easily be corrected.
- Many users are still dealing with the in-the-past-lack-of-attention-to-stability technical debt. Things really are better now.
-
One possible action:
- Support up to 3 branches other than HEAD
- Of these, designate one as LTS.
- Support LTS for (say) at least 2 yrs beyond release, a year after designation.
- As LTS branch becomes older, the bar for backporting goes up...
- ...and in any case only applies to Stable features.
- Talk with ghcup team about when to designate a new LTS release, and which -- so that it can be the recommended release from moment of designation.
- List of necessary but not sufficent requirements
- e.g. Stackage LTS exists for this release
- e.g. works with HLS
- more controversial: buildable on tier-2 platforms
-
Problem: if we (implicitly) encourage users to do "big jumps" from one LTS release to the next, they won't get deprecation warnings, etc. from intermediate releases.
-
Ben and Andreas will discuss the meta-proposal described here (see "one possible action" above):
- Perhaps designate a release (well into its lifecycle) as an LTS
- Stable features in LTSs receive backports for a year after designation
-
-
Draft tooling recommendation
- Holding the token: Trevis
-
JMCT: What would a GitHub mirror that posts to GHC GitLab look like?
-
Jappie: catagorizing head.hackage https://docs.google.com/spreadsheets/d/1xNAn7qE1X7waI7lAIh9lOUKGuEb9HnRwGWNicaywASk/edit?gid=251085624#gid=251085624