Skip to content

Regular Meetings

Jump to bottom
fendor edited this page Oct 18, 2023 · 12 revisions

Regular HLS meetings

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

The meetings alternate between a general meeting and an issue/PR triage meeting. For the general meeting the chair should establish an agenda (either in advance or at the start) and take minutes in this doc.

Meeting 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