owned this note   changed 5 hours ago  
Published Linked with GitHub

Cabal meeting (2025-08-14)

Previous meeting wrap-up

  • the CI PR went great; CI is now working fine after the initial hickups.
  • there seems to be not enough risk appetite among the maintainers at this moment to start the second part of CI overhaul before the next release (the pruning the old things)
  • it maybe more respectful to the second phase PR author to communicate this early, rather than late or after a long discussion that may or may not change the outcome
  • Francesco is managing the new logo things

Current affairs

  • Matt doesn't like hlint, which Phil pushes.
    Some people are mildly positive about hlint (e.g. Artem; also Bodigrim was eager to approve hlint PRs).
    What should we do about it (if anything)?
    • Matt says that he is not that bothered about changing anything but just offered a small pushback.
    • Nobody seems to care very much.
    • Mikolaj recommends, given that, let's stick with this experiment for some more time, so that we don't change our opinion too often based on who comes to the devs meeting more or less often at a given time.
  • Brandon discovered https://resources.github.com/github-secure-open-source-fund/ and HF has been notified. It happens we co-maintain hackage-security, so this is on topic even just for this reason. Assuming it's realistic, would somebody like to voluteer (in coordination with HF, I guess) to apply for the grant and do the work (it is for one developer only and rather modest, right? or one dev per package? one grant per package)?
    • no volunteers at the meeting and it's unclear how easy it is to get the money; fortunately HF is engaged.
    • "how easy it is to get the money" is HF's problem if we do this
    • also the real question may be "who's willing to (a) wade into hackage-security code (b) figure out things that need to be done wrt security"
  • Mikolaj asks, more generally, can we have for cabal somelike like the Open Collective that funds HLS improvements (https://opencollective.com/haskell-language-server)? Are we, as maintainers, interested in 1. getting the funding in this way (or other way) for any sensible and well defined cabal projects by any devs, 2. funding the maintanance itself from such donations, 3. other?
    • Matt says that he is willing to set this up and then x-fer the keys to Haskell foundation (he did this already for HLS open collective).
    • yay!
  • Matt wishing to thank Artem for the 3.16 release retrospective document and for his management of the release.
    • applause

Review needed

Food for thought

Cabal meeting (2025-07-31)

Previous meeting wrap-up

  • Release success. 2 regressions so far

  • Juilan's CI rewrite https://github.com/haskell/cabal/pull/11072

    • the patch is in decent state (Artem)
    • lingering small issues (Brandon)
    • are we "burning bridges" to the old GitLab-based approach as Julian requested in the past? – NO
    • Brandon: there are downsides (weird Docker images) but GitLab isn't in a great shape either, so all things considered I support it
    • Artem: there're pros and cons but it looks like a promising direction
    • Mikolaj says it looks good from what the reviewers say
    • By default, the release manager decides to be or or not be an early adopter of the new CI and then we'll decide further based on the experience
    • It would be good to have a list of sources of all the images, especially those not coming from github, for security, troubleshooting, etc.

Current affairs

Review needed

Food for thought

Cabal meeting (2025-07-17)

Attendance: Brandon, Mikołaj, Kristen, Francesco

Previous meeting wrap-up

  • Release of Cabal 3.16
    • No objection to go ahead with plan 3c (normal relase, then another 3.16.1.0 release once bugs stop trickling down
  • How to create and maintain (removals!) a list of cabal mainainters
    • Maybe we are not se keen on that after all; let's wait for volunteers with a plan

Current affairs

Review needed

Food for thought

Cabal meeting (2025-07-03)

Attendance: Brandon, Mikołaj, Hécate, Matthew, Kristen, Artem

Previous meeting wrap-up

  • Release of Cabal 3.16
    • Release tracking ticket
    • Acknowledgement of Artem as the release manager
      • Matthew says: he's doing a great job so far.
    • Artem confirms the assumed consensus really holds about:
      • the date of cutting the branch (and consequently what PRs get included by that time –- not as backports)
        • Brandon is under the impression that Artem has given up on the other listed PRs being ready for the release
          • no objections to that
        • Hecate mentions github.com/haskell/cabal/issues/10915, but the fixes are already merged to cabal and probably everywhere else
      • that we release 3.16.0.0, which is Cabal-the-lib-onl
        • no objections, given that Artem bears the brunt of the extra work (coordination)
  • Cabal proposal process (https://github.com/haskell/cabal/pull/11006)
    • Matt asks about the team page idea (whether to have one, and what the purpose is)
    • Matt asks about the location of the proposals (separate repo vs in-tree)
    • no objections to move forward (merge, implement, etc.)

Current affairs

  • How to create and maintain (removals!) a list of cabal mainainters so that contributors and stakeholders know there are any and whom to contact (though there's the cabal-devel mailing list)? That would also be a step towards more structured governance, again for the benefit of non-mainainer contributors.

  • Further planning of the Cabal 3.16.0.0 release

  • Mat mentions a model of private dependencies that will help in understanding the behaviour of the PRs about that

  • relocatable binaries on FreeBSD: https://github.com/haskell/cabal/issues/11034

Review needed

Food for thought

Cabal meeting (2025-06-19)

Attendance: Mikolaj, Hannes, Brandon, Matthew x 2, Rachel, Francesco, Artem

Previous meeting wrap-up

Nothing to report

Current affairs

  • Hannes introduces Rachel as working on cabal.project plugin for HLS as part of GSOC.

    • Work is based on Julian's cabal.project parser rewrite.
    • Hannes says he can look at reviewing the MR
    • Matthew will do last 10% and take all the glory.

  • Release of Cabal 3.16

    • Ben sent out a call for boot library maintainers w.r.t. the planned GHC 9.14 release: alpha in June and final release in September. Cabal is expected to release 3.16.0.0 version of the library.
    • Do we want to release the library earlier and the tool a bit later (prefereably before the final GHC release)?
    • Artem: I think it'd be good to try to release the library before the alpha release of GHC (June) and the tool before the final GHC release (September).
      • In past releases we've finalized the extensions after alpha1 and released as soon as posssible afterward. (Brandon)
    • stack is doing prereleases with ghcup support. Should we try it for 3.16?
    • we will decide the hands-off (main) release manager next meeting; volunteers welcome

  • Introduce a cabal proposal process?

    • Matthew has proposed the investigation of the idea of a having a proposals process for cabal.

      • Motivation 1: Make it easier to make decisions about bigger things
      • Motivation 2: Improve documentation about bigger features and overall project direction
      • Proposal: https://hedgedoc.well-typed.com/twubgfbyRoae5NKjHwbBPA?view#
      • Email or message Matthew with specific comments. In the exploratory phase at the moment.
      • Artem: I like this idea.

    • Brandon has some concerns specifically about our organization for this

      • We often have a shortage of meeting attendees, but we're expected to review proposals during the meeting. (See for example here.)
      • We should define a quorum of people who are qualified for proposal review (not general discussion; we should expect and encourage the proposer and supporters/detractors to join) and skip proposals if such quorum isn't present

    • Brandon & Artem: There should be some escape hatches to avoid making decisions if expertise is not available.

      • Mikolaj: Perhaps an upper bound of 6 weeks on making decisions after being requested.
      • Brandon: If quorum is not reached regularly then there are bigger issues than this process!

    • Francesco: Is this process just bureaucracy? What sort of examples might have gone through this process?

      • Matthew: Some examples, removal of v1- commands, removal of other legacy code can be very difficult to gain concencus. The Hooks build-type work and also private dependencies features suffered from not having a forum to discuss the ideas.
      • Matthew: It should be a process which developers want to use to gain consensus in order to make the changes they want.

    • Francesco: we need a PR on this proposal.

Review needed

Food for thought

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.

Select a repo