Try   HackMD

Cabal meeting (2025-06-05)

Previous meeting wrap-up

  • Even older meeting wrap-up: old PRs are closed, as discussed some time ago and communicated on the PRs themselves in advance. ~30 closed.

Current affairs

Review needed

Food for thought

  • Phil would like to get "Override imported package version equalities" work finished. PR-9150 was my original quick attempt at this. I'm not sure that the method used there will be the one to go with but I would like to get import version overrides available soon.

Cabal meeting (2025-05-22)

Only 2 attendees (geekosaur and grayjay), so very abbreviated meeting and no action.

Previous meeting wrap-up

Current affairs

  • Matt asked about a number of PRs of his going back a month or so that haven't been reviewed yet. Are we missing things in our review-needed checks?

Review needed

Food for thought

Cabal meeting (2025-05-08)

Previous meeting wrap-up

Current affairs

  • How is our triaging? Are PRs and issues waiting for our input a long time? Maybe today we could look at these tickets, not the usual needs-review.
    • from browsing a few dozen, it turns out we are reasonably switft reacting to PRs and issues.
  • Is the traging group still active? Can we help them? Maybe today we could look at these tickets, not the usual needs-review.
  • f-a will go through all old PR (< 2022) and add the tag propose-closing.

Review needed

Food for thought

Cabal meeting (2025-04-24)

Previous meeting wrap-up

  • Opinions on #10900 were given. If you have more thoughts, chime in! (Added by f-a, shepherded by Javier.)

Current affairs

  • any fresh regressions? any complaints about 3.14.2?
    • nothing worrisome so far, it seems \o/
  • hie-bios uses now cabal path, will be shipped with the next HLS release
    • Should reduce HLS startup time noticeably

Review needed

Food for thought

  • Artem: please, consider adding your favorite short/middle-term tickets to the "Considered for 3.16" milestone.

Cabal meeting (2025-04-10)

Previous meeting wrap-up

  • 3.14.2 released
    • do we want to keep tagging at the start, as in 3.14.2 or move it to where it was, much later?
    • supposedly there was some mixup with candidates and the tags, but Mikolaj can't remember anything
    • trade-offs
    • let the next release manager decide –- the current order seem to favour a more tight, but more laborious release
  • LTS
    • Brandon and others since discussed on Matrix and the agreement seems to be to postpone LTS to when we can reliably predict which release will work for many future GHCs, etc., etc. to avoid the 3.12 case that can't work with GHC 9.12 (and a couple more other changes make it problematic) so can't be LTS despite our hopes (and lots of great work backporting)
    • we also need to rethink how to do an LTS and how to plan for it, e.g., given the frequent GHC releases and the tight coupling of cabal and GHC

Current affairs

Review needed

16 PRs have the "attention: needs-review" label

Food for thought

Cabal meeting (2025-03-27)

Attending: Kristen, Mikolaj

Previous meeting wrap-up

Current affairs

Review needed

16 PRs have the "attention: needs-review" label

Food for thought

Cabal meeting (2025-03-13)

Previous meeting wrap-up

Current affairs

  • Is it time for cabal 3.14.2 yet?
    • It would be great to first review and merge and backport and merge the backports for the regression fixes that are ready. But let's ask around how urgent the existing fixes are for the users.
  • Is 3.12 (still) the Long-Term Support release? Will it be still supported? See its mention in https://github.com/haskell/cabal/pull/10367
    • Let's ask Brandon.
  • Do we (still) need the preferred version feature? Please anybody who knows, write the reason in this ticket: https://github.com/haskell/hackage-server/issues/1345

Review needed

20 PRs have the "attention: needs-review" label

Food for thought

Cabal meeting (2025-02-27)

Previous meeting wrap-up

  • We should block the GitHub Merge button for everyone but Admins. (Some discussion in #10714)
    • Mikolaj failed to enact the change due to technical problems. Ideas welcome. This is not critical, is it?
    • Actually it seems Mikolaj succeeded, see the ticket.

Current affairs

  • Regressions. How are we doing?

Review needed

17 PRs have the "attention: needs-review" label

Food for thought

Cabal meeting (2025-02-13)

Previous meeting wrap-up

  • Should we block the GitHub Merge button for everyone but Admins? (Some discussion in #10714)

    • YES (no objections)
    • If no more objections till next chat, let's do it at the next meeting.
    • Mikolaj will do offline

Current affairs

Review needed

18 PRs have the "attention: needs-review" label

Food for thought

Cabal meeting (2025-01-30)

Previous meeting wrap-up

  • [This time let's take an action:] Should we block the GitHub Merge button for everyone but Admins? (Some discussion in #10714)

    • YES (no objections)
    • If no more objections till next chat, let's do it at the next meeting.

Current affairs

Review needed

16 PRs have the "attention: needs-review" label

Food for thought

  • Hécate: should we start recording cabal performance in a principled way? E.g. running benchmarks (that we apparently have)
    • Mikolaj: sure, let's experiment!
    • it seems, annotating master branch tip commit in the pipeline that runs after a PR merge may be a good start (and maybe end)

Cabal meeting (2025-01-16)

Previous meeting wrap-up

Current affairs

  • Should we block the GitHub Merge button for everyone but Admins? (Some discussion in #10714)
  • Could we agree to this transition away from lukko #10724 so that it can be marked "PR welcome"? No objections, so let's mark it PR-welcome.

Review needed

21 PRs have the "attention: needs-review" label

  • Could be good if #10644 is merged ahead of #8889 (mentioned in meeting of 2025-01-02) as it fixes one of the problems mentioned with #8889 as it stands.

Food for thought

Cabal meeting (2025-01-02)

Previous meeting wrap-up

Current affairs

  • 3.14.1.1 release

    • Hécate: At this point, RCs have to be uploaded on Hackage (step 4)
    • Mikolaj: let's remember to make Cabal-hooks one of the candidates, as per the wiki release checklist! It's only needed once per major version, though, I guess with .1.0 suffix, normally.
    • Hécate: I want to take the habit of releasing regularly 3.14 for patch versions.
    • announcements? yes, when they're available in GHCup

  • Regressions in 3.14

    • Initial configuration of programs does not use build-tool-depends #10692
    • Julian reported a regression w.r.t. relative paths in the packages field of the project file. But no one was able to reproduce it so far…
    • the haddock subcommand is confused with sublibraries https://github.com/haskell/cabal/issues/9586; likely not a regression

Review needed

17 16 PRs have the "attention: needs-review" label (down 1 2 from previous meeting)

Food for thought

Cabal meeting (2024-12-19)

Previous meeting wrap-up

Current affairs

Review needed

18 PRs have the "attention: needs-review" label

Cabal meeting (2024-12-05)

Previous meeting wrap-up

  • (Brandon) Re home-grown lenses: intentional and expected. It's not like we want a dependency on lens or even microlens, and van Laarhoven lenses themselves are quite simple and easily defined on the fly (and are upwards compatible if at some point we do decide to eat a huge dependency). (Both of those are Profunctor lenses, but all we need are twanvl's Functor lenses. That said, even in lens the basic Lens type only requires Functor; it's more advanced optics that need Profunctor.)
    • the others we should seriously consider fixing, though: can we use a glob library rather than hacking up our own slow one? How about optparse-applicative? Etc. (Mikołaj mentions logging as another.)
    • Mikolaj is convinced by the argument above not to change our deps policy (only boot packages) until there's a pressing need, which there doesn't seem to be right now.
    • Conclusion: consider GSoC or HSoC exploratory projects

Current affairs

  • 3.14.1.0: will there be a post mortem? was there an announcement?

    • the release is not yet complete; it looks like Hécate is still waiting on access to downloads.haskell.org so the release artifacts can be uploaded, then the Hackage candidates will be released and the announcements sent out
      • Hécate: I need to pester Gershom

  • (f-a) PRs with extensions (like this one), what do we do about them? Do we accept? (I am especially talking about ViewPatterns). I am not fond of extensions because of GHC monoculture and most importantly readability for future contributors. We could also decide to be more liberal in — say — cabal-install and more strict on Cabal-syntax/Cabal.

    • action: see if we have style guides we can cannibalise for extensions. Report back (f-a).
    • note that as of #9718 Cabal is GHC-only because it requires DataKinds and the Symbol kind. In particular, MicroHS has no type level functionality and isn't intended to, so this places it out of its reach.
    • we've also had one request for OverloadedRecordDot that got blocked by our support window
      • @9999years: This is a great example I think; OverloadedRecordDot solves a big ergonomic issue with structs (field names being globally unique makes them really challenging to use), but also OverloadedRecordDot brings its own pain points. It's better than the alternatives, at least…
    • also, pretty much every recent submission by GHC folks used every GHC extension they could get CI to accept, so we will have an uphill battle there
      • @9999years: I think this is less of an uphill battle than we'd think — it's not too hard to get CI to reject new language extensions & require explicit approval to add new ones.
    • @9999years: I would be more concerned about a GHC monoculture if there was a competing compiler we could hypothetically be breaking compatibility with. Also in absence of a Haskell2020 report it feels unfair to tell people to keep writing the language like it was preserved in amber 15 years ago.
      • I think we should add all/most of the GHC2021/GHC2024 extensions to the .cabal files and add a CI check that forces new extensions to be documented or justified.
      • we have one, as mentioned previously: MicroHS. notable: no type level programming. (It does support OverloadedRecordDot and a number of other non-type-level extensions. But lack of support in ghc 8.10.7 is still a problem, because that's still in our support window.)
      • Mikołaj says we need a style guide

  • #10605: Recent work on shallow clones for source-repository-package broke some invocations with abbreviated or non-canonical refs, which cannot be git fetched directly.

    • Consensus is we should revert the change and do a proper deprecation cycle, but it's not clear how to best do that on top of recent work. I'm (@9999years) in favor of a roll-forward fix to restore the old behavior without directly reverting the commit responsible.
      • Hécate: Agreed

Review needed

20 PRs have the "attention: needs-review" label

  • #10573: cabal-validate: Better output verbosity defaults. +91 -97 lines, pretty straightforward and makes ./validate.sh nicer to use.
  • #9367: Use response files for ghc invocations. +191 −29 lines, comes with tests. Needs review from @mpickering.
    • approved, currently in cooldown

Food for thought

  • #10594, redesigning the PR template

    • there are some comments, but @9999years says they're mostly unhelpful and I must agree. We need actionable suggestions.

  • 3.12 LTS

    • with no release as yet (granting 3.14 took precedence), so far it's not doing much
    • should it be? Do we know if an LTS makes sense at this point?
    • If it does, should we consider using 3.14 as LTS instead on the grounds that profiled dynamic support is significant and it can't be backported to 3.12?
      • although "LTS" won't mean much if the same thing happens in 3.16
    • if not, should we consider releasing 3.12.2.0 soon? Or do we have enough changes/fixes?
    • (Side note: API check on the 3.12 branch from 3.12.1.0 release on says we're clean. One API change with a backward compatibility pattern synonym, plus one added instance, neither of which is in our code but a dependency (Data.Graph). https://paste.tomsmeding.com/QnNIQGrC)

Cabal meeting (2024-11-21)

Previous meeting wrap-up

Current affairs

  • cabal format deprecation is blocked by Gershom. What's our way forward?
  • Breaking changes
    • Reject PRs without a template?
    • Fixup the PR template: https://github.com/haskell/cabal/issues/10575
    • Maybe have a job that comments on PRs if they're missing tests or release notes
    • Testing third-party codebases like cabal-doctest in CI?
    • Start small: Define particular APIs that respect back-compat etc.
    • Find which APIs people use in Cabal-the-library
  • Git property tests in long-tests
    • We can move them later in the cabal-validate pipeline, lower the count of properties generated
  • Lots of home-grown internal libraries in Cabal: lenses, globs, CLI parsing, etc. etc.

Review needed

22 PRs have the "attention: needs-review" label

  • #10524: Add dependency provenance information to solver errors

    • Huge diff (+2450 −1254) but mostly mechanical changes, threading through
    • Errors look like this now: rejecting: memory-0.18.0 (constraint from cabal.project requires ==0.17.0)
    • Next: Line numbers in error messages??? E.g. cabal.project:12 requires ...
    • Kristen:
      • I was surprised by some of the affected fields.
      • Would it be possible to splitit somewhat?

  • #9367: Use response files for GHC invocations

    • Fixes builds with very large packages (thousands of modules) which hit command-line argument length limits
    • Finally ready after an extensive process fixing --keep-tmp-files, pretty small diff

  • #10562: Tracking issue for cabal-validate devx

    • I have a bunch of ideas to discuss here :)
    • #10573: Better verbosity settings for cabal-validate output (skip printing config and build plan by default, show build and test output by default)

Food for thought

  • 3.14.0.0 API breakage https://github.com/haskell/cabal/issues/10559

    • let's disallow PRs without a template: we'd not miss a changelog if we already did
      • Rebecca: but the template isn't great, we should improve it

  • 3.14.1.0 release: Hécate will start on it ASAP

Cabal meeting (2024-11-07)

Previous meeting wrap-up

Current affairs

  • New regression found in 3.12.1.0: #10504: active-repositories: none fails if ~/.cache/cabal/packages/hackage.haskell.org doesn't exist

    • Can fix it with a partial revert of #8944 (see #10506). But it blows out the whole idea of #8944, so, naturally, the author of #8944, Javier, doesn't want it.
    • Artem doesn't have a strong opinion but leaning towards reverting because it looks like a nasty regression. Submitted the revert in #10506.
    • Arguably, there's a workaround – to create the index with cabal update once and then get back to building with active-repositories: none.
    • Mikolaj: let's revert and think later. There may be good reasons to bring back some of this functionality, but anything that breaks needs to be reverted until then IMHO.

  • CLC suggests adding Cabal(-syntax?) into the set of "core libraries", which, effectively, gives emergency powers to the CLC in case Cabal maintenance experience a catastrophic failure.

  • Set of backports for 3.14.1 that need approval:

Review needed

21 PRs have the "attention: needs-review" label

  • #10525: Make source-repository-repo: in cabal.project a parse failure
    • This is a backwards compatibility break; previously this was a warning, meaning it could easily get buried under compilation output.
    • A warning is really bad UX here – a source-repository-repo being completely ignored means you're getting a version of a dependency you don't expect, which usually causes compilation errors which obscure the warning at the top of the output!
    • When I hit this, I usually recompile again instinctually so the compilation errors aren't buried under a ton of [1 of 3] Compiling Control.Concurrent.CacheVar.Internal (...) output, and on the second run the warning isn't emitted at all! This makes it very frustrating to diagnose.
    • Are we OK with this backwards compatibility break? This effectively means that in the future we won't be able to add a field (like build-depends:) with the same name as a stanza (like source-repository-repo). If it's not OK, I can turn it into a warning.

Food for thought

  • Artem wonders if our approach to auto-formatting can be improved. Maybe we shouldn't require it from contributors' PRs and instead have another pre-step in the release checklist: to reformat before cutting a branch. We already added "update fourmolu before cutting the branch", so it's effectively the same thing, just the diff will be larger, probably.
    • The context is another unhappy contributor (link).
    • Brandon thinks: the Ci job, instead of whine, could fix the formatting by itself.
    • After more discussion on Matrix, people seem to be leaning towards scrapping auto-formatting altogether.

Cabal meeting (24/10/2024)

Previous meeting wrap-up

Current affairs

  • cabal-install 3.14 release, pending

    • #10459 validate.yml sync
    • #10468 new ghc 9.12 options
      • do we care about -pgmJSP, -optJSP?
      • (Brandon) what do I need to do to mark options as affecting artifacts / the store?
      • we still need to find answers to these questions ^^^; Rodrigo will investigate
      • it seems, unless somebody argues otherwise, this PR does not block the release of cabal-install (but it would be good to have)
    • one more option will be coming but won't affect this PR
      • or will it? it (well, its inverse) might affect the store but shouldn't make a practical difference
    • 4 PRs have the "needs-backport 3.14" label
    • #10290: a regression from 3.12 with --program-suffix

  • Hécate: We need to have a documented deprecation process which mandates a period of three releases. I would like to suggest this: https://github.com/haskell/cabal/wiki/Deprecation-Process. This will help manage our own work, but also the users' expectations, and thus create more trust in us.

    • Mikołaj: We should have a TL;DR with actionable items at the beginning.
    • Hécate: We have decided to try it out with the deprecation of cabal format

Review needed

  • #10448 ensure sdist test runs on the correct ghcs

23 PRs have the "attention: needs-review" label

Food for thought

Cabal meeting (10/10/2024)

Previous meeting wrap-up

  • Cabal 3.14 release redux, deferred from last meeting
    • except Hécate won't be around again, so must defer again until next meeting
    • (Brandon) I just noticed we don't have tags for the 3.14 release?
      • (Artem) we probably could push the tags at least (provided we know which commit was HEAD at the time): people always come complaining about tags when we miss them
      • Hécate: is the correct commit 1eaa6af21 or a370e62cd?
      • (Brandon) Moved tagging to before making the Hackage release. I think in the past we've not only forgotten to tag, but sometimes the Hackage release isn't the one we tagged?

Current affairs

  • (Brandon) #10431 Mergify require all-green CI (merged)
    • originally intended to replace having to list everything in branch protection
    • due to a confluence of GitHub and Mergify warts/bugs?, will hopefully fix Mergify merging PRs before CI finishes (cf. #10424)
      • it didn't, so now I am waiting on Mergify.io to get back to me
    • I have opened a bug against Mergify for merging before CI completes; sadly, they have not provided me with even a bug number, much less a link
    • There is also a GitHub branch protection bug, which I haven't yet reported: when checking a PR, all jobs with the same name must pass for branch protection to be satisfied, but when merging only the first needs to pass
      • this means the docs skip hack is risky without #10431 or other insurance against premature merging due to branch protection incorrectly going green too early.

Review needed

  • (Brandon) #10421 Makefile rule to do local checks

    • This rounds out answering Matt Pickering's round-tripping complaint #10263
    • Needs one more review
    • hlint is currently divorced from the action used by CI. The latter has some peculiarities that make me wary of switching CI to use this check instead
    • The only other check that might make sense to do locally is the doctests, for which there is a bitrotted Makefile rule that needs to be updated if we want to add it.
      • Should we? Or is that more along the lines of running validate.sh locally?

  • (Brandon) #10429 debug LTS prereleases

    • the LTS prerelease I added has been being skipped for some reason; this is intended to debug it and will be followed up hopefully by a PR to fix it
    • Needs one more review before it can be merged and backported so debugging can begin

  • (Rebecca) #10428 add --tasty-arg to validate.sh

    • This lets you do e.g. ./validate.sh --tasty-arg --keep-tmp-files, which makes debugging failed tests much easier.

  • (Rebecca) #10427 Add --pattern arg to cabal-testsuite

    • This lets you do ./validate.sh -s cli-suite -p HaddockKeepTmpsCustom to filter tests in cabal-testsuite with the same grammar you can use to filter Tasty tests. Super helpful for running tests locally.

  • (Rebecca) #10393 haddock-project: add CommonSetupFlags

    • Pickering has some questions about this: "Why are haddock-project options defined in Cabal library at all.. I understand nothing to do with you but it's a cabal-install command. I am not sure this is the right direction of travel"
    • This matches the other commands, so it's beyond my knowledge of Cabal.
    • This PR is the last blocker for #10292 (expand and unify --keep-temp-files), which itself is blocking #9367 (use response files for GHC arguments).

21 PRs have the "attention: needs-review" label

  • (Brandon) Lots of these are old, review and ask if they're still alive? action: Brandon will take care of this.

Food for thought

  • (Brandon) #10372 overnight testing for tier 2 platforms

    • What tests should be run for "tier 2" platforms (including those we currently only build at release time with no testing, such as FreeBSD and i386-linux)?
    • Relatedly, are there any tests that would be better run at merge time rather than every time a PR is pushed to?

  • (Brandon) I intend to start parting out the validate workflow into individual actions, partially in support of the above and partially to make the workflow easier to digest.

  • (Artem) re: meeting notes: how about using one gigantic log of these notes in one document? Pros:

    1. don't need to wait until a new one is created to add an item;
    2. easier to review past notes with just "Find in page";
    3. helps discoverability: e.g. we can put the link to The Log document in many places (Matrix chat description, Calendar event, etc.)
    • (f-a) Consider this: max doc-length on HackMD is 100,000 lines.
      This document is 66 lines, so we have ≃ 58 years, given a fortnight format.

Cabal meeting (26/09/2024)

Previous meeting wrap-up

Current affairs

  • Cabal 3.14 release redux
    • Congrats!
    • Big discussion postponed to another meeting.

Review needed

  • #10376 (Brandon) Makefile targets for fix-whitespace
    • Javier asks whether it takes care of CRLF, is this enabled in our repo?
  • #10363 (Brandon) switch back to Apple AArch64 builder
    • Mac jobs are only a couple minutes slower than Ubuntu!
    • #10372 overnight job to validate and make prereleases for Intel Macs, since older ghcs won't work on AArch64 runners
      • this needs some additional work, since it was relying on state from the validate job
      • is it really a good idea to waste GitHub cycles on rebuilding stuff over and over? also applies to #10274
        • GitHub is a business. Yes, it is owned by Microsoft, but Microsoft is not in the business of giving free CI/CD to open source projects, and in particular both it and its subunits are expected to turn profits. As such, GitHub must buy its own runners, which are paid for by its commercial customers; we, as free users, get to use spare cycles on their runners as long as we don't interfere with their paying customers. Wasting cycles therefore impacts us both directly (our jobs compete with each other for those spare cycles) and indirectly (they compete with other free users the same way). Therefore, wasting cycles on constantly rebuilding things is only going to cause us problems.
  • #10361 (Brandon) continue CI when tests fail
    • the Validate post job will catch these and fail the build afterward, I think
    • this has some interaction with above note, but I think not much because it's only tests and is not really different from the successful case
  • #10273 (9999years) show why configuring dependencies failed
    • helps debug nix (and other build system?) failures
  • #10320 (9999years) convert validate.sh to Haskell, add more flexible test filtering
  • #10314 (9999years) improve assertion messages for testConfigOptionComments
  • #10292 (9999years) unify multiple --keep-temp-files options between subcommands
  • #10366 (jasagredo) create temp files in temp directory (Higher relevance for Windows users)

26 PRs have the "attention: needs-review" label

Food for thought

  • #10379 system-filepath won't install with ghc 8.0
    • (Brandon) I think we need an old-ghcs job that tests custom-setup

Cabal meeting (12-09-2024)

Previous meeting wrap-up

Current affairs

  • Cabal release (here checklist)

    • #10336 Artem is busy, should we wrap it up (f-a and geekosaur).
      action: f-a will do it, then ask Artem+Brandon review. (done)
    • Mikołaj notes we need to release cabal-install fairly quickly once we put out Cabal 3.14 out.
      If we don't, we will have problems (e.g. custom-setup's problems).
      • Rodrigo notes that ghc 9.12.1 alphas will be coming soon
    • Brandon asks if it will be released to Hackage. If it only for GHC, do we need to release it on Hackage?
      • Rodrigo notes that the GHC team would prefer it to Hackage (to avoid git submodules).
    • 3.14 version bump set to merge
    • needed: LANGUAGE additions now, option additions by first alpha
    • any chance we can get a fix for #10290 in before a cabal-install release?

  • (Brandon) I need to set up a test repo and work out how to stop Mergify from merging PRs with active discussion/reviews (cf. above mis-merge)

    • this probably won't happen until after 3.14, between the release rush and medical issues

Review needed

  • 22 PRs have the "attention: needs-review" label

Food for thought

  • Brandon: are we ok we blowing an ℕ just for a “for GHC”?
    It would be weird for users jumping from 3.12 to 3.16.
    It could be a point release (e.g. 3.13.1.0).
  • Brandon notes that this way of working with GHC (GHC release -> Cabal-the-library release -> next GHC -> rushing cabal-install release) will leave us with little time to do anything else.
    A release takes effort and time, so Mikołaj thinks this way of releasing should not be a common occourrence.
    • famous last words…
  • May need to reopen 3.12 backports and get Windows fixes in so the io-classes workaround will go in
    • 3.12 still considered LTS

Past Cabal meetings

Past meetings were kept in individual notes, with back-links to earlier meetings. The last such is here.

Last changed by 
 
geekosaur
0
1
829

Read more

Cabal meeting (29/08/2024)

Previous meeting notes.

Aug 30, 2024
Read more from geekosaur
Published on HackMD