Skip to content

Regular Meetings

Jump to bottom
Fendor edited this page Mar 6, 2024 · 12 revisions

Regular HLS meetings

We have a bi-weekly meeting. Attendance is open, contact the chair for an invite.

In the meetings, the agenda is discussed, followed by triaging issues and discussing open PRs, potentially reviewing them if time permits. For the meeting the chair should establish an agenda (either in advance or at the start) and take minutes in this doc.

Meeting minutes

06/03/2024

Chair: Fendor

Attendees: Fendor, Milky, Zubin, Patrick

Agenda:

  • No agenda
  • Release HLS 2.7.0.0

Minutes:

  • Release 2.7.0.0 is done
    • Only minor hiccups
  • Issue triaging

21/02/2024

Chair: MPJ

Attendees: MPJ, Jose, Patrick, Jan, Elodie

Agenda:

  • WT contract
  • GSoC
  • Go to dependency definition
  • Zurihac tooling workshop
  • Renaming generated stuff

Minutes:

  • WT contract
    • Things we might want WT to focus on
      • Release management as unusual
      • Flaky ghcide tests
      • Reviewing work on hls-graph
    • MPJ draft agreement
  • GSoC
    • Elodie might want to mentor
  • Go to dependency definition
    • 2 main issues
      • Some refactoring, can delay
      • GHC 9.8 conflict fixing
    • MPJ proposal for doing things differently
      • Too much work, too late to switch
    • We can check with Zubin to see what he wants
    • Elodie maybe start work in March
    • MPJ write issue about “let it fail”
    • Jan might help out with the PR
  • Workshop
  • Generated stuff
  • SemanticTokens delta PR
    • Still unclear what to do
    • We can move forward and just write a clear comment

07/02/2024

Chair: MPJ

Attendees: MPJ, Fendor, Zubin, Jan Hrcek

Agenda:

  • ZuriHac
  • Meeting schedule change
  • WT contract renewal
  • Release for ghcide-test-utils, #3994

Minutes:

  • ZuriHac
    • Haskell Tools workshop
    • M asked to talk about HLS
    • Unclear if Zubin is coming
    • Fendor is going to go
    • Might only arrive one day before
    • Maybe we can do HLS on day 2
    • Look for good Zuirhac issues
    • Might have some keen people after the workshop
  • Meeting schedule
    • Move 1 hr later
    • Make the issue triage meeting a generic meeting
  • WT contract
    • Last tranche got sucked up a lot with release management
    • WT multi-home-unit blog post
    • Ghcide test suite audit
  • Releases
    • Should we even build binaries?
      • Still useful to retain knowledge
      • Can at least simplify
  • Ghcide-test-utils issue
    • Zubin will fix
  • GSOC
    • Zubin write proposal for structured diagnostics
  • Fake ghc dependency is annoying
    • Can we just use the GLASGOW_HASKELL macro as a proxy?

24/01/2024

Chair: MPJ Attendees: MPJ, Fendor Agenda:

  • Issue triage
  • GSoC

Minutes: LSP config issue Runners issue GHCup and releases Issues with the vanilla channel MPJ: I think we should just accept that we have to wait and see what Juilan does MPJ: build everything against vanilla like Julian wants, it’s compatible with downloads.haskell.org, and ghcup vanilla MPJ: if there are problems with the setup we can just direct people to ghcup GSoC MPJ: I’ll write up inlay hints idea Zubin: write up go-to-implementation and misc; and structured diagnostics Fendor: talk to cabal folks and maybe make a proposal for cabal plugin; maybe improve test performance Idea for IOG folks Use fat interface files instead of core files Fault tolerant GHC pipeline Various GHC issues HLS plugins in one package People generally in favour

10/01/2024

Chair: MPJ

Attendees: MPJ, Zubin, Fendor, Nathan

Agenda:

Minutes:

  • MHU
    • Next HLS release will have it in
    • Can ask people to test by building cabal HEAD
      • ghcup compile works? Nope
      • ghcup install cabal --force -u https://github.com/haskell/cabal/releases/download/cabal-head/cabal-head-Linux-x86_64.tar.gz head
    • Works for macos and windows, too
  • GSOC ideas
  • Release
    • This week ideally
  • Testing
    • Another test suite library seems unnecessary
    • More parallelism would be nice
    • Splitting the test job is still viable, need to batch the components
  • LSP scheduling
  • Exactprint patch up this week
  • Cabal release
  • Call for maintainers
    • Fendor write something up to call for people

13/12/2023

Chair: MPJ

Attendees: MPJ, Zubin

Agenda:

  • Release status
  • 9.8 support
  • Exactprint
  • MHU
  • What else WT is up to

Minutes:

  • Release
    • 2.5 is out
    • Julian built FreeBSD bindists
    • Recommended channel is updated
    • Will be a new GHC version in January
  • 9.8 support
    • Zubin has an exactprint patch
    • Might be a lot of exactprint changes in 9.10
    • Some remaining allow-newers, might be able to get rid of them
  • MHU
    • Would be nice to get some pre-release testing
    • Maybe write a WT blog post?
    • Need a cabal release
      • Zubin ask Matt what’s up
  • Other WT stuff
    • 9.8 support
    • Test suite
      • Pick up Fendor’s work?
    • Nothing more to do with implicit-hie right now
    • Better cradle failure diagnostics? Structured diagnostics for hie-bios
      • Maybe progress reporting for hie-bios?

15/11/2023

Chair: MPJ

Attendees: MPJ, fendor, Zubin

Agenda:

  • Release HLS 2.4.0.1
  • Head.hackage, how to use in the future
  • Stan plugin
  • New Label “status: needs review”
  • Stack CI is on CircleCI
  • Multiple home units status
  • PRs needing attention

Minutes:

  • Release
    • 9.4.8 binaries
    • M message Julian to talk about release
  • Head.hackage
    • Next time try to have PRs for all the patches we need, use source-repository-packages to pull them in, so we can see the list of things we’re relying on and we know there are PRs in flight
  • Stan
    • Sure why not
    • Need to add the submitter to the repo so they can be in codeowners
  • Needs review
    • Useful to indicate if something is ready to review even if it has e.g. CI issues
  • Notes plugin
    • Maybe doesn't pull its weight, but we have a relatively relaxed policy so far
    • Nice to have an example of adding a go to def rule
    • Maybe it should be disabled by default? Encourage GHC devs to try it out
  • CircleCI
    • MPJ might port it if bored
    • Might push our cache usage up with could be bad
  • Multiple home units
    • Implicit cradle stuff is in HLS
    • Can remove the stuff from hie-bios
    • Very close to it “just working”
    • checkProject is now misnamed, it checks the component, but won’t load all the components in the project
    • Could have some more configuration options
      • checkComponent
      • checkPackage
      • checkProject
      • M make an issue
  • WT stuff
    • Multiple home units
    • Compatibility stuff
      • Fixing plugins that need exactprint
    • Test improvements
  • Propose dropping 9.0 ahead of schedule
    • Not widely used
    • Would simplify our CPP
  • Mergify issues
    • Doesn’t work well because the CI is not reliably green, and then it ignores the PR

18/10/2023

Chair: fendor

Attendees: Nathan, Elodie

Agenda:

  • Release HLS 2.4.0.0
  • Release HLS 2.3.0.0

Minutes:

20/09/2023

Chair: michaelpj

Attendees: michaelpj, nathan, david (left early), fendor, elodie, zubin, profpatsch

Agenda:

  • The chat situation
  • Release CI is broken
  • Release 9.6.3

Minutes:

  • HF business
    • Secrets
      • Ailrun has access to add secrets
      • Fendor will prod to actually do it
      • Richard Eisenberg is fallback contact, has admin access to bitwarden etc.
    • OC funds
      • Make M an admin so we have someone else active
      • Done!
  • Better GHC API chat
    • Might need someone to join a WG to talk about this
  • Releases CI
    • Might be fixed now?
    • Zubin has a PR for downgrading checkout action to fix something
    • Could maybe just remove the checkout action if we have to
    • Macos stuff is broken
      • Probably simpler to use the GHC nix stuff now
      • Zubin going to try this out
    • GHC 9.10 will not build on old debian images any more, so we’ll need to drop some architectures for some versions
      • Might need to hack the scripts a bit
  • Release for 9.6.3
    • Zubin is going to do it
  • What’s the deal with ghcup revisions?
    • Someone needs to implement it
    • Maybe we could pay for it if it’s not too much work
    • Zubin is going to chat about it
  • Chat situation
    • Lets just use a matrix room, MPJ will set up
  • HSOC projects
    • End of project admin
    • Elodie
      • Finishing off some comments
      • Make issues for stuff that doesn’t get done
      • GHC patch is still in progress
    • Nathan is finished, has emailed
    • Jana is finished
      • Still have some PRs in flight, not clear what to do with them
      • Fendor tries to push them over the finish line in the next months
  • Test flakiness
    • Zubin has done some work on it
    • A bunch of the func-tests are redundant, Fendor will delete some

06/09/2023

Chair: michaelpj

Attendees: michaelpj, fendor, nathan

Agenda:

  • Triage

Minutes:

  • Did triage
  • Chat situation
    • Seems like we need to commit to one platform
    • Maybe let’s at least make a Matrix room and advertise it

23/08/2023

Chair: michaelpj Attendees: michaelpj, nathan, david, jana

Agenda

  • HSOC project status
    • Make sure everyone is on track to be done soon, cut off extra work if it’s not feasible
  • Release
    • What’s going on with the client settings rule?

Minutes:

  • HSOC
    • Nathan
      • A few PRs to finish, want to get to benchmarking
    • Elodie
      • Mostly there, going to finish off the main PR and make issues for the rest, some comms issues with Zubin
      • Will write a blog post
    • Jana
      • Trying to get the code action POC in a good state
      • Lots of leftover bugs
        • Many of them dependent on the parser being in a better state
      • Subsequent writeup
      • Would be good to write something about why we have a cabal parser of our own
  • Releases
    • 9.4.7 should be out today
    • MPJ almost has the workspace/configuration stuff done
  • MPJ question about client settings
    • Might need to be the way it is
  • Multi-unit patch
    • Nearly done
    • Problems with implicit-hie
      • Maybe we need to take it over?
      • Zubin going to take a look
  • .hls directory
    • Annoying that people will have to gitignore it but seems unavoidable
      • Should mark it clearly in the release notes
    • Could maybe put the other caches in there

09/8/2023

Chair: michaelpj Attendees: fendor, michaelpj,nathan, milky

Agenda:

  • Triage
    • Did triage
  • Release
    • Had some issues with the release CI
    • Windows build issue
    • Probably not going to get the configuration fix up asap unless MPJ gets it done today
    • Might need to do another release next week if there’s going to be another point release
    • Will go ahead with the release today
  • Talked about Fendor’s test improvement PR

26/07/2023

Chair: michaelpj

Attendees: fendor, michaelpj, zubin, elodie, nathan, milky, christiansen

Agenda:

  • Ailrun has access to twitter email account, do we want to take ownership of that email address
    • Proposal: Add Ailrun to Bitwarden, then they can enter the email and password
  • HSOC project status
  • Zubin update
  • New Release 2.1.0.0
    • Proposal: Release manager: Fendor
    • Proposal: Time with next GHC release
  • Release strategy, coordination between HLS and GHC
  • WT plans

Minutes:

  • Going to take over the email address
  • HSOC update
    • Nathan
      • 2 PRs in flight
      • Working on plugin error infrastructure
      • Merging refine import and explicit import plugins
      • Blog post is next on the list
    • Elodie
      • Fighting the test suite, rogue failing test
      • Compiler versions are painful
      • Branch is mostly working
      • Need to write tests for the main feature
    • Jana
      • Working on completions still
      • Working on a simple parser for cabal files
        • Would be nice to upstream this
        • But there was a lot of effort on cabal file parsing that got stuck
        • Can be cruder, don’t have to care about error messages
  • Zubin update
    • 9.8 support incoming
      • Would be nice to get a HLS for the second alpha
      • Unclear who’s paying for it
      • Ghcide is in head.hackage
    • ModuleGraph patch https://github.com/haskell/haskell-language-server/pull/3232
      • New benchmarks
      • Discussion with Pepe: no benchmarks regress, unclear what more we can do
    • Multi-component stuff
      • This patch may be the last one
      • Assuming no bugs!
      • A hie-bios patch too https://github.com/haskell/hie-bios/pull/409
      • Fendor: create a ticket outlining what we need for everyone to benefit from cabal/hie-bios improvements.
  • Test suite
    • Zubin would like to work on it
    • Fendor has a patch to test handlers directly
    • Harder to deal with commands
    • Discuss on the issue tracker
    • Fendor: create a ticket outlining the testsuite imrpovements
  • Next release
    • Fendor volunteers to be release manager
    • Ideally 9.4.6
    • Not 9.8 alpha
  • Release strategy
    • Users want a HLS release as soon as there is a GHC release
    • Really: users want binaries as soon as there is a GHC release
    • Currently we’re restricted because of GHCUp: can’t add binaries for released versions, have to do a new release, which adds much more overhead
      • If we could lift this restriction it would help a lot
      • Maybe Zubin could do it
    • Probably will still need a real release for major versions, but lagging there is more okay
  • GHC version compatibility again
    • Come on, let’s drop GHC 8.10 already
  • WT plans
    • Test suite
    • GHC support

28/06/2023

  • Write down the process for this meeting for the next time a new person needs to hold the chair.
  • Improve transparency of these meeting outcomes, why and how did we arrive at the WT contract and other expenses (I don’t think we have other expenses right now)
    • Maybe publish this meeting document
    • Publish short blogs to opencollective how we are using the funds
      • Overlaps with the WT blog posts
  • Did NASA write us an email?
    • We should set up an official email address
    • Perhaps list the main contributors on the homepage
  • Plugin performance
    • It should be easier to measure plugin performance
    • Ghcide-bench only measures memory, not cpu speed, both might be interesting.
    • It should be possible to see how much memory each plugin is using during a normal run.
  • WT Contract
    • Contract is over already, need something soonish
    • What do we want them to do?
      • Performance improvements?
      • Updating to newer GHCs?
      • Reviewing plugins
        • Often have performance woes
    • CI should be done by contributors if possible because it is relatively easy
      • If a contributor has time and motivation, WT should be doing it otherwise to make sure it happens on time.
        • Also, they take responsibility to make sure it happens and in case of issues.
      • How can we make contributors cut the releases?
      • How much work is a typical release?
        • From half a day to one week, but depends on the state of release CI
        • Nightlies motivates us to have a working release CI all the time and invest in its performance
      • Simplify sending PR to ghcup-metadata
    • Zubin is working on module graph performance optimisations
  • HSoC Progress
    • Who needs reviews?
    • Code Resolve PRs, Michael is looking at them
  • 2.0.0.1 release
    • Fix CI issues (ran out of space)
    • More linux machines (self hosted by Moritz)
      • Self-hosted might not be sustainable eventually due to the bus factor
        • Moritz is doing it for free, had to fix issues while on vacation
    • No new changes
    • Maerwald wants to improve the release checklist documentation
  • Nightlies
    • Might improve reliability of CI
    • Where to store bindists? S3?
    • Maerwald creates a prototype

14/06/2023

31/05/2023

  • Welcome HSOC folks
  • Release 2.0.0.1 (disk usage issues)
    • Why not just add binaries for old releases rather than doing a whole new release?
    • Zubin: it seemed easy enough
    • Julian: would be nice to know when releases happen
      • Julian has a meeting with GHC team regularly and talk about it
      • Would be nice to not have more meetings!
      • Could do with some kind of channel for this
    • Julian could do with clarity on when the release is signed off on
      • Add a section to the release process doc saying “two out of three of Michael/Zubin/Julian have to sign off”
    • Julian wants to add some stuff from his own release checklist to the main HLS one
  • Issues with the release
    • Tweak the scripts to do some more aggressive cleanup
  • Which versions of GHC/HLS should be recommended?
    • Ideally don’t want a combination of versions where there aren’t HLS binaries
    • Need some kind of policy
    • Awkward to add binaries for HLS later because GHCUp doesn’t support revisions yet
  • GHC version support (is it time to drop 8.10?)
    • Lots of people still on it
    • Vscode extension can figure out which HLS/GHC versions are compatible, GHCUp can’t (yet!)
    • 8.10 is the main source of CPP atm
  • WT contract renewal (blog post on the way: https://www-staging.well-typed.com/staging-hls-wt-r8kdpi/blog/2023/05/hls-work/)
    • MPJ to send out message about it

17/05/2023

  • Zurihac
    • Fendor and Zubin and Michael will be there
    • Talk about making HLS more maintainable with GHC help
  • Exactprint issues
    • Can’t use it on typechecked source currently
    • Not very well documented
  • Plan Zurihac projects
  • MPJ write a GHC ticket about related locations for diagnostics

03/05/2023

  • HSOC
    • Hopefully doing all three projects
  • MPJ update on LSP work
  • Should revisit easy issues for HSOC folks and Zurihac

05/04/2023

  • HSoC
    • We have two in
      • More resolve methods
      • Jump-to-def for non-project packages
      • Inlay hints
        • MPJ write a proposal
  • Tests are flaky, what can we do?
    • Ghcide tests seem quite flaky atm
    • Might be down to 1 in 3 failing
    • Turn off fail-fast on the test job matrix
      • It’s helpful for the succeeding ones to succeed
  • Dropping 8.10
    • Stackage LTS is still on 9.2, that’s our proxy for community adoption
    • Other community proxies: ghcup recommended compiler?
  • 1.10 release retrospective
    • Had some issues with Hackage uploads
    • Issue with diffing against the previous version, because it was made off a branch
    • Should try and do cabal build haskell-language-server from Hackage at the end
    • Maybe just version everything identically?
      • Means we’ll end up with pointless releases of some packages that haven’t changed
      • But means that version bumping is very simple
      • What about making everything multiple public libraries?
        • Does Hackage support it?
        • Does stack support it? No
        • Does nixpkgs nix support it
        • Generally a new feature
    • Zubin has some release CI improvements coming
    • Difficulty with darwin as expected
  • HLS governance
    • MPJ made an attempt at a descriptive document:

08/03/2023

Nobody turned up, MPJ and David had a chat.

  • Contributor's Workshop in Zurich
    • David would like to have some HLS content. Maybe ask Zubin/Pepe if they’d come and present

08/02/2023

  • GSoC
  • Stabilising out use of the GHC API
    • Still tricky
    • Pepe: I’d like to see a writeup of any proposal to tidy up the CPP, we’ve tried before and not succeeded very well
      • Or at least we tried a compatibility layer
  • Multiple home-units
    • WT are working on it
  • Ghcide in head.hackage???
    • Apparently it works at the moment, maybe it won’t in future
  • 9.6 compat
    • Zubin has tried, ghcide mostly seems to compile
    • Plugins, unclear. Depends a bit on ghc-exactprint
      • Matt will get ghc-exactprint into head.hackage
    • Someone else is funding this work from WT
    • Might try to put the tier 1 plugins into head.hackage
  • Next release
    • Point release after 9.2.6 (early next week), get binaries for it and also do a couple of backports
    • Julian will do it
    • Zubin will do a couple of backports to a release branch
    • Zubin needs to give Julian upload keys for downloads.haskell.org
  • Github CI
    • Makefile is crucial
      • Deals with the dynamic linking cleverness
      • Windows doesn’t need it because reasons, so has a simpler implementation
    • MPJ look into loading bits of matrices from files, solve the GHC version issue
    • Caching
      • Controlled by a repository variable, can be off or non-fatal
      • Zubin is happy
  • Governance
    • Julian: two issues
      • Telling people what we did with their money
        • WT is supposed to make a blog post about how the money was spent at some point
      • Resolving disagreements
    • MPJ: also legitimacy

11/01/2023

  • Github CI PR
    • Zubin: the gitlab CI works fine for me, but it would be simpler to just rely on one system
    • Scope
      • FreeBSD support is just one CI file
      • cabal-cache usage should be optional
    • S3 needs some secrets
      • Need some kind of secrets-sharing scheme
      • HF has a Bitwarden organization that we could maybe use
    • Also need to pay for S3
      • In principle HF might provide S3 in future, but this needs some consideration
      • David: I need a proposal for it, but I’m generally in favour of having an institutional account
      • Maybe start by using Julian’s and see how it goes from there
    • Runners have limited accessibility
      • But can work on this
      • Sharing across the haskell org
    • Cost-benefits of caching for release CI
      • Reduces build time, but so does parallelizing the jobs
      • Zubin: built times for release CI aren’t such a big deal
      • Michael: maybe we can just toggle the caching of the artifacts so we can turn it off if we’re worried
    • Darwin environment
      • Setup with brew currently, which has been problematic in the past and may be problematic in the future
      • Zubin: I’m concerned about this, it’s tricky. Using nix gives us the same toolchain that GHC uses
      • Julian: the main thing we install that’s tricky is LLVM, and we can pin that manually. Also it mimics what users would do if they built it themselves.
      • David: what question is this CI job answering? Is it about source buildability or binary compatibility?
      • We’ll have the same problem sometimes on the Github MacOS runners
      • Maybe we can do both or have one as a fallback?
      • Maybe we can pin the brew repository?
        • Zubin would be happy with this
    • Can we use the cabal-cache stuff for the normal CI?
      • Some issues with cabal not knowing about ABI
      • Should be doable
    • Arguing about supporting FreeBSD
      • David: it would be nice if we were discussing this in a more coherent way
  • Minor release because of more 9.4 compat?
  • Supporting the most recent version of GHC
    • Might make releases easier
  • Item for later discussion: can we make it easier to update the bounds/versions for plugins when we do a release
  • Actions:
    • David: get some HLS members access to the HF bitwarden account
    • Michael&others: review Julian’s PR
    • Julian: pin brew repository in the PR
    • Julian: put AWS secrets in the HF bitwarden
    • Julian/someone else?: later? use cabal-cache in PR CI workflows

14/12/2022

  • Release so we get binaries for new GHC versions
    • It’s been very slow and makes us look bad
    • The gitlab stuff is still working
    • Moving to GH would require a lot more work
    • Zubin is working on a release
  • Proposal: GitHub CI is slow
    • Increase cache-size with cabal-cache and s3 bucket, paid with opencollective money. See https://github.com/haskell/ghcup-hs/pull/694 for inspiration
    • What’s the problem?
      • We need >10G of cache space
      • Don’t cache on failure, so if a job fails and it was lacking in caching, then it will redo everything lots of times
    • Didn’t we get special treatment from github in the past?
      • Pepe can ask Patrick
    • https://github.com/haskell/haskell-language-server/actions/runs/3689923567
      • Longest Windows test job is 1h50m
        • Not great but not terrible either
    • Can we find out how big the cache is?
      • We’re using 43gb of 10gb !
    • Cache key: maybe it should just be hash of plan.json? Plus platform + GHC version?
  • What happened with the migrating to GH/self-hosted runner discussion?
    • Julian: it’s still bad being yoked to the GHC CI, we’re stuck with their platform support and the GHC devops don’t have time for us
    • Zubin: we can try it so long as we don’t lose support for some platforms
    • We agreed that Julian is going to try it
  • Zubin’s memory-usage PRs
    • Module graph
    • Will try to get them in before the release, but release anyway
  • Managing our releases quickly
    • Coordinate releases with bugfix releases of GHC
    • We need GHC in GHCup in order to build our binaries
    • So we have several steps
      • GHC releases
      • GHCup adds it
      • We build binaries
      • GHCups adds our binaries
    • Does Julian know when GHC gets released?
      • Not necessarily, no coordination there
      • Someone else could also do the metadata update!
    • Maybe the HF can help, might be nice to have a GHC release manager who has a wider scope and can deal with some of these issue
      • David basically agrees, unclear how to get there
    • Longer RC period for GHC would help?
      • Don’t have RCs for minor versions
  • WT update
  • Action items
    • Julian: Figure out a way for the HLS folks to get notified when there’s a new GHC version in ghcup
    • Zubin: Rotate the release manager for HLS
    • Pepe: ask Patrick about our special github status
    • Fendor: check that the caching system is doing some thing sensible

15/11/2022

  • GHC Medium-term priorities *
  • WT status update
    • Got the gitlab CI fixed up
    • Get existing patches merged
    • Review the 9.4 compat work that other people have been doing
  • MHU & better multi-component support? Current status and is there anyone working on it?
    • Needs more support in Cabal, Matthew is working on it

02/11/2022

  • Issues with flaky tests on CI
    • We don’t really have a lsp-test expert to help us out

18/10/2022

  • Should we move off gitlab CI? (Julian)
    • https://gist.github.com/hasufell/c26f6bb1897bf98ef73a48bb1cf9a9c4
    • Move most of the release CI for HLS and Cabal to GHA from GHC Gitlab
    • We don’t do it today because Gitlab supports more architectures
    • Causes problems
      • Multiple CI configurations for dev+release
      • Not enough testing on release architectures
      • Insufficient support on GHC Gitlab
      • Runners are manually maintained, by multiple people
      • Competition for resources on GHC Gitlab
    • Big problem: Mac M1
      • Github might get it but not yet
    • Other minor ones:
      • FreeBSD
    • Might need to pay for our own runners
      • … but we already have it on Gitlab!
      • Could maybe hook up Moritz’s existing runners to GH also
        • Would still have issues with sharing resources
        • Moritz has M1 and also linux-aarch64
    • Advantages of GHA
      • Maintain some runners… but only the non-standard ones
    • Using the same runners that build GHC ensures that HLS is build in the exact same environment as GHC
      • Could use the same docker image that’s used to build GHC
    • Providing one of Moritz’s runners for projects using GHA would be useful generally
      • Also useful if it was available to other core projects like e.g. bytestring
        • Otherwise we find out later that they don’t build when they hit GHC CI
      • Don’t necessarily need it for all the HLS CI runs, just for releases
    • The GHC M1 CI is broken anyway thanks to brew :(
      • May ultimately want to move environment setup to nix anyway
    • FreeBSD is in a bad state
      • The GHC FreeBSD runner is broken for 6 months
      • Matthew: FreeBSD is not actually a supported platform for GHC (!)
    • Platform wishlist
      • Darwin M1
      • FreeBSD x86 (mostly Julian?)
        • They also have aarch64 but that’s very niche
      • Linux x86/aarch64
    • Can do some simulation via docker
      • Very memory-constrained and slow
    • If we need more resources for machines we can ask the HF
    • Kind of just hard to get good Macs
      • Rented hardware is often unreliable
      • Getting it yourself requires someone to physically handle them for you
    • Actions:
      • Moritz hooks up some runners to GHA
      • Julian experiments with moving some of the CI config to GHA
      • Moritz+Julian come up with maintenance backup plans so we don’t have a bus factor of 1 for the machines
  • How is the WT work going?
    • Zubin was on holiday
    • More patches to come!
    • Existing patches for memory usage
      • Might need some benchmarking
      • Will try to get them in this week
      • Should have similar
    • codeAction/resolve could also be useful
      • Avoid computing and sending code actions
  • Retrie
    • Can we strip out the dependency? Seems like it’s not actually used that much
    • Zubin might look into it later
  • New GHC diagnostic infrastructure
    • Too much CPP to gain much benefit
  • Maybe multiple versions of GHC support again
    • Seems very painful, status quo is also painful
    • Can we make the CPP less painful?
    • Current HLS still has big problems

05/10/2022 (Issue triage meeting)

  • Chat about supporting fewer versions of GHC
    • David is pro
    • Michael is worried about it moving pain to supporting multiple branches
      • Also slow process for features reaching people on old GHCs
  • Fendor: MuniHac 7.10 - 9.10.
    • Which tickets are suitable for MuniHac? Preferably, we have something for each skill-group. I am instructing a couple of people to bring a completion system to the cabal plugin.
  • Extract function code action
    • Might get done at MuniHac

21/09/2022

  • Zubin: can we remove snippets
    • It’s a bit unreliable
    • Often unclear what to do, e.g. a lens looks like a function but you never want to apply it
    • Record snippets will still work
    • Needed for completion item resolve
    • Working on it -> Zubin
  • Pepe: Dropping support for 8.6 and 8.8
    • Meta is still using 8.8 but Pepe would be happy to drop it
    • It’s very expensive to support lots of versions
    • M: we said we would wait for a LTS, but it has been ages and I don’t think anyone will fault us
    • Technically the policy says we should drop 8.10 but that seems premature
    • Zubin: remember to purge hie-compat, also maybe need to tweak hie-db
    • Actually do it -> Pepe
  • Deprecation policy
    • Michael: maybe we should stop saying we wait for LTS Stackage, instead just for “the ecosystem to catch up”
  • Publicising the WT work
    • Write a short blog post on the WT blog and send it to the OC subscribers -> Matthew
    • Next steps: updating plugins
  • Multiple home units
    • Zubin has done some work for hie-bios
    • Fendor has done some work in cabal, thinks there may need to be some redesign needed
  • Michael: Plugin tiers
  • Release retro
    • More CI jobs
      • Julian has done something
  • LSP Types rewrite

07/09/2022 (Issue triage meeting)

  • Triaged all issues until now

24/08/2022

  • Defining a core set of plugins (MPJ)
    • It would be useful so we could have a support status between “none” and “full” (all plugins; may never happen for some versions of GHC)
    • Maybe need more categories?
      • Core: we won’t release without this
      • Tier 1: we will try not to release without this but we might have to (e.g. class plugin)
      • Tier 2: best effort, depends on maintainers
    • TODO: MPJ start a discussion on github
  • Status of the Opencollective proposal and the new release?
    • Proposal has been sent to WT
    • Some contractual details to work out due to opencollective
    • They’re starting work on it soon
    • TODO: MPJ follow up on email thread
  • GSOC progress
    • Aarush has made progress on folding ranges, have agreed for the project to span a longer period
    • Colten has a PR for record dot completions, just need to get it over the line
  • OsPath PR
    • Worried about merge conflicts with the HLS part
    • It’s annoying because one of the main functions can now fail, will cause lots of errors
    • Lots of confusing discussion about locales for filepaths
  • Sync the progress of big PRs?

10/08/2022 (Issue triage meeting)

27/07/2022

Attendees: pepe, zubin, Matt, sloorush

  • Dumb WT work proposal written by MPJ: https://docs.google.com/document/d/1Amz038212wOQn22ACXXO_JSI5LAzwgRJAefDEHTAyJw/edit
    • Pepe: looks good to me
    • Pepe: could we extend it to cover more than one release?
    • Zubin: we should decide on a release schedule
    • Pepe&Zubin: Tie the release schedule to GHC releases?
    • Matt: pay WT to automate HLS releases even more, make it easier
      • Pepe: this has more value than polishing the GHC compat code
    • Zubin: need to give access to upload to Haskell.org to release maintainer
      • Pepe: use a Github secret to store it and make it available to the script

13/07/2022 (Issue Triaging Meeting)

Attendees: michael pj, fendor, maerwald, ailrun

Agenda:

  • What Labels do we actually need?
  • Cleanup old labels
  • Triage new issues

Minutes: (reproduced, might be inaccurate)

  • Goal: Remove fine-grained label tracking, as we don’t have the resources to keep them up-to-date.
  • Inconclusive:
    • “Component: *” labels
      • Very fine-grained, does someone actually use these?
      • Labels should not replace a proper search engine
      • GitHub Issue Search often finds unrelated issues
  • Overview of the most important labels
    • Status labels:
    • Type Labels:
    • CI Label
      • CI (Continuous integration, for all CI related issues)
    • Guidance
      • level: easy (The issue is suited for beginners)
        • We have to be careful here to not accidentally mark hard issues as easy, so we don’t discourage new contributors
      • level: hard (This issue is not suited for beginners)
    • Priority
      • priority: high (High Priority Item)
        • We omit any other priority as we don’t think it will help us in general. We won’t have any use for anything except High priority.
    • General Purpose
      • ZuriHac (This issue is suitable for ZuriHac Hacking sessions)
        • Temporary Label
      • Performance (Issues about memory consumption, responsiveness, etc.)
        • General performance issues
      • GHC (issues with particular GHC versions)
        • Helpful for GHC devs

Proposal: We always have to assign both, status and type labels to each issue.

Outcomes:

  • Renamed old Labels with an “old_” prefix
  • Deleted unused labels we don’t think are helpful
  • Started migrating old labels (e.g. prefixed with “old_”) to the new labelling style

29/06/2022

Agenda:

Minutes:

  • HLS affiliating with HF
    • Zubin: we already did it?
      • Looks like we did
    • So we can probably hand David the money
    • Get Matthew to hand over permissions
    • Probably fine for Matthew etc. to keep access
  • What to spend the money on?
    • GHC compatibility work
      • Basically covered already
      • Basic PR is up, how much work is left?
        • Haven’t looked at plugins yet
        • Getting the exactprint stuff working
      • Scope of paid work doesn’t cover all the plugins?
        • Maybe we could pay for this
        • Not all plugins are “core”/doable, e.g. formatters
    • Zubin: fixing up test suite and CI failures
      • Dealing with flaky/disabled tests
      • Bryjan from HF has been doing some stuff on GHC CI
        • David: he’s going to be busy indefinitely
    • Release management
      • Zubin: a lot of the work was changelogs and bumping versions
        • Hard to do in a PR since it’s unclear if it’s already been bumped since a release
          • Does policeman help?
            • Not updated any more, doesn’t support multi-package project
        • Also a lot of time on Windows
      • What’s our release schedule?
        • Monthly is a bit much
        • Quarterly? Definitely after a new GHC version
        • Let’s try and come up with this offline
      • Fendor: could we make releases easier if we had better changelog management e.g. like cabal does?
        • We have some automation which scrapes PRs
      • Julian: maybe we could just pay someone to do it, not necessarily WT
      • Knowledge/scripts are getting contributed back
      • Julian: would be good to coordinate ghcup, GHC, vscode-haskell, HLS releases
      • People are generally okay with paying someone to do the release when we do it
    • Better diagnostics
      • It’s too hard to identify why things are going wrong
        • Stale state on the server
        • Setup issues e.g. cradle failures
      • Try to make sure that we have logs or diagnostics for common problems
    • Pepe: hard to specify open-ended tasks
    • MPJ: propose to just make a somewhat open-ended grant to WT to work on HLS with some priorities
  • GSOC
    • Colten
      • Issue at the moment lies in getting the types to show up in the HIE AST
      • Types seem to be getting lost in the renamer
      • Might need to patch GHC, making a reproduction issue
        • Maybe can do something in hie-compat?
      • Might want to do completions first since they’re less likely to be blocked on GHC
    • Aarush
  • Action items
    • Make a release policy offline
    • Come up with list of “core” plugins offline
    • MPJ: schedule an issue triage meeting
    • MPJ: come up with a draft proposal for WT to do some work

01/06/2022

Agenda:

  • Say hi to each other
  • Welcome GSOC students
  • Discuss plans for Zurihac?

Minutes:

  • Popular issues
  • PRs that need help
  • Opencollective funds
    • What do we do with it?
    • Who’s responsible for it
      • Matthew has the keys now, we could move it
      • Provisional decision: get David to do it as the HF
      • Then it looks more reuptable
    • Had a summer student last year
      • Fendor
      • Are there obvious candidates?
    • Can pay a consultancy to do stuff
      • Better for boring stuff
    • WT is an obvious choice but COI with Matthew
    • Pepe: need to get HLS updated to the next GHC version
      • Not student-friendly
      • Zubin has already worked on this
      • Will be recurring
      • A client of WT is paying for it this time, but can’t rely on that
    • Brainstorm of other stuff:
      • Bunch of stuff to do for making home units work
      • Finish off big existing PRs e.g. Zubin’s
      • Mystery hanging issue
      • Performance/memory usage
        • Don’t have a clear overview
        • Unclear what’s our fault what’s GHC’s fault
        • Needs analysis
        • Benchmark suite doesn’t seem to show leaks
        • Much easier if we have example codebases to work on
        • Can we make it easier for the community to help?
          • Matthew is going to talk about this at Zurihac
      • Better logging and monitoring
        • Not useful for users, not useful for us atm
      • Doing release management
        • Boring and unsexy
        • Maybe have multiple release managers?
  • Maintenance is difficult
  • Zurihac
    • Matthew, Fendor, and Michael are going
  • Issue tracker
    • Lots of setup and cradle issues
    • Issue triage is a problem
      • Javier used to do lots
      • GHC has a monthly issue triage meeting
      • Maybe we could have a triage meeting alternating with this one?
    • Prioritize things
  • Error improvements in GHC
  • Action items:
    • Make a list of proposals for the money and get people to vote on them (Michael)
    • Follow up with the HF board to check for red flags about moving the money (David)
    • Start a list of easy things to do for Zuirhac (Fendor)
    • Register as a project for Zurihac (Fendor)
    • Make some priority labels (Nick)
Clone this wiki locally