Previous meeting notes at: https://hackmd.io/rPjlPdfZQ3uxjU8k8X5mWg Current affairs Francesco: We are nearing the release. Been pairing with Mikołaj. Brandon: We have no CI that catches wrong bounds on Hackage. See https://github.com/haskell/cabal/issues/9835 Andreas: Our CI doesn't do good cache management: https://github.com/haskell/cabal/issues/9850 Rodrigo will work on https://github.com/haskell/cabal/pull/9468 Kristen: Code reviews (import tree PR, etc) Review needed

Previous meeting notes at: https://hackmd.io/TN_SpaezQXyMiePfykjbew Current affairs Mikolaj: who would like to release 3.12.1? Maybe we'd first release only Cabal 3.12.0 for GHC 9.10 not to block them? I think we'd not include in 3.12 the Custom Overhaul proper, but we'd include (almost) everything currently on master? Any objections? Hécate: Mikołaj, Hécate and ff-aa will take care of the release of the Cabal and Cabal-syntax librarise for the release of GHC 9.10 Hécate: We need to engage with people during Haskell events (local meetups, Hackathons) to get more people engaged, even in things that are not primordial, like QA tester on the Windows & macOS platforms. Mikolaj: shall we move forward implementing this HF proposal (Custom overhaul in the Cabal library, for a start): https://github.com/haskellfoundation/tech-proposals/pull/60#issuecomment-1945681169

Previous meeting notes at: https://hackmd.io/xWsbOqZwTOG0INmykIj2Dw Current affairs Hécate: 3.10.3.0 Release: All version bound backports seem to have been merged, I will then do the following: Send a PR to bump all the version numbers in the 4 packages' cabal files Create release candidates on Hackage Hécate: We need to step up our game regarding Windows documentation: https://github.com/haskell/cabal/issues/9713

Previous meeting notes at: https://hackmd.io/vjZgVTpmQHyh6JO2g-I1dg Our repo: https://github.com/haskell/cabal Current affairs Mikolaj: the promised 3.10 Branch Maintainer job description. The main goal is to help the users (e.g., Linux distro maintainers) that will compile cabal 3.10 from source many years after the last 3.10 release. Your job is to take ownership of the 3.10 branch in the repo and do your best to keep it in good shape until it's officially retired, which includes:note, highlight, participate in, initiate discussions related to the 3.10.* releases and encourage PRs (e.g., for bound bumps) whenever the users seem to need them alert all maintainers if impossible happens and a new release in the 3.10 series may potentially make sense (but don't worry, releasing 3.10 is not a part of this job at all) keep CI on 3.10 branch operational, e.g., by backporting CI fixes, for as long as feasible merge or bring up for discussion outside PRs to the 3.10 branch

Previous meeting notes at: https://hackmd.io/UsYDbySERP2SWfE7jRRdqg Current affairs Hécate: about https://github.com/haskell/cabal/pull/9527 ; It's all good, this is the last PR to backport for 3.10, mergify will take care of it and then we can set labels for the system on which the QA was run. Mikolaj: do we require PRs for Hackage revisions of old cabal versions (3.6-3.8 and, another category, <=3.4)? https://github.com/haskell/cabal/issues/9616 Artem: my view is we should be more lenient here (recall that CI is dead on old branches) and ask people to test locally that it builds and submit a PR;welcome and encourage PRs, not too vigorously for very old versions Mikolaj: Does it make sense to maintain a couple of older cabal release branches (e.g., keep CI passing, request and merge bound revision PRs)? If so, would a brave developer step up and take over, e.g., the 3.10 branch, after it's stabilised (3.10.3?) and until it's officialy retired (years from now)? 3.8? 3.6? https://github.com/haskell/cabal/issues/9531#issuecomment-1880666888 Artem: would be nice to have someone but I doubt we can find those heroes. Core devs don't seem to have cycles for this.

Previous meeting notes at: https://hackmd.io/mQjghm2zRgWgcyD4XKhBqA Current affairs Hécate: Cabal 3.10.3.0 release timelinehow do we handle the tar bump? #9557Option α: release 3.10.3.0 without tar bump, release tar in a later point release. Option β: release tar bump with 3.10.3.0. (risks: problems pop up and GHCup does not bless it with “recommended” status). Julian dixit: “…but given that 3.6 is now doing worse on windows, it might just make sense to bump to 3.10 anyway”. And he just did it Hécate: Let's backport. f-a will do the backport once the PR is approved. Julian endorses this release. Julian: Only submit vanilla bindist file, ghcup distributes its own bindists too

Previous meeting notes at: https://hackmd.io/s/H1dR5FkUp Current affairs 3.10.3: are we missing anything else? Does Julian want anything else?[Covered: Hecate voluteers] Mikolaj asks humbly: Could somebody ask Julian? [Done: approved for 3.10.3, Javier handled the backport, merged.] this is the only apparent non-merged candidate PR (conditionally recommended by grayjay): https://github.com/haskell/cabal/pull/9550 [MK: Now merged.] #9525 should be merged too, bot got stuck? —F We've agreed to release ASAP and not to block the release on anything else, any backports, etc. Hécate: cabal path's UX is subpar at the moment and I can't sign-off on shipping it. It only serves as a glue command for cabal2nix, but only reads the user-wide config file and environment variables. We can:

Previous meeting notes: https://hackmd.io/Wm5vF1ZrQ8qIWMt60vyhzw Current affairs Andrea: The issue with GHC 9.6, -fplugin and cabal register seems to be affecting many users, including stack and rules_haskell: https://discourse.haskell.org/t/ghcs-fplugin-any-changes-between-9-4-7-and-9-6-2/7656/4. We had an issue (#9375) opened last month and we merged a fix (#9384) about three weeks ago. I am not expecting the release gods :joy: to get their hands dirty again but could we make a minor release for this patch?Hécate: No problem for a 3.10.3.0 patch release, we need to ship https://github.com/haskell/cabal/pull/9459 anyway Hécate: No plan for patch releases for 3.8 and 3.6. Andrea: #9374 (Guard PackageInfo behind cabal-version: 3.10) we need to make a decision about what to do. Further discussion is at #9331. Mikołaj has a plan: https://github.com/haskell/cabal/issues/9331#issuecomment-1792219043

Hi everyone, The Cabal development community is sending a call for participation in our quality assurance (QA) programme. We are looking to improve the quality of the software we ship on the Windows platform. This is a continuous and incremental process, and this where you (yes, you!) can shine. The reason for this call is that many of Cabal's PRs cannot be properly tested in predictable and clean GitHub runners. This challenge is exacerbated by a lack of Windows users. As a result, we are looking for people with access to Windows machines and willing to test the nightly releases of Cabal on real-world code bases. We hope to get bug reports out of this process and improve the Cabal user experience on Windows. The concrete approch we propose is based on a dedicated GitHub project. In particular, contributors put notes for the QA team in tickets and PRs. These items are then automatically collected in a place where you can see what needs testing: https://github.com/orgs/haskell/projects/3. The whole process is facilitated by the nightly builds of cabal-install that we provide. So, you don't have to compile the tool yourself to get the latest features that need testing.

Previous meeting minutes: https://hackmd.io/6RJCTZ0dQMuToo3uFzfLcA Current affairs Switching to Fourmolu 0.14: https://github.com/haskell/cabal/issues/9424 Adds script to automatically generate GHCup metadata for Cabal releases: https://github.com/haskell/cabal/pull/9411 Design a 'Hooks' build type to replace 'Custom': https://github.com/haskell/cabal/issues/9292Andrea's comments:I think the implementation of the build-type is secondary; and indeed not useful by itself. We need to come to an agreement on a design for the new Cabal/package-builder interface that will augment the CLI interface. I don't think we will be able to completely remove the CLI interface. If we offer a shim for it, we will end up in a situation where stack will be able to build cabal packages with build-type custom (thanks to the shim) but cabal-install won't! We need to build an architecture that is gradually extensible and where backwards compatibility is not a major road block.

Dear all, cabal-install 3.10.2.0 has been released and is available in ghcup as well as on downloads.haskell.org. This release allowed the cabal team to refine our release process. Especially the effort put in by our QA testers has been crucial in validating contributions changing user-facing behaviour. Release notes for cabal-install 3.10.2.0: https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.10.2.0.md

Previous meeting minutes at https://hackmd.io/C8C5jFniT6-rk6I2C9NwlQ Current Affairs (tickets and PRs of interests) Use response files for ghc invocations #9367: https://github.com/haskell/cabal/pull/9367 PackageInfo functionality is not guarded behind cabal-version. #9331 : https://github.com/haskell/cabal/issues/9331We have to be more careful in the future to guard new functionality behind the cabal-version field of the file format. Terminology: Internal libraries are out, sublibraries are in! This is the terminology that was already used in several blog posts, and as such we must unify the vocabulary: https://github.com/haskell/cabal/pull/9371 The exact-print parser topic has been raised from the dead once again, and the situation is that many people seem to be interested in pursuing experiments that cannot be realistically included in the cabal parsing infrastructure. Due to the extreme sensitivity of the subject, a proposal will have to go through the Technical Working Group before it's approved, so that development can be smoother.

Cabal 3.10.2.0 status Distribution blockers: Windows paths corrupted in CI -> https://github.com/haskell/ghcup-metadata/pull/127error: https://github.com/haskell/ghcup-metadata/pull/127#issuecomment-1742107642 (https://github.com/haskell/ghcup-metadata/actions/runs/6371387038/job/17293285342#step:3:15214) Julian has some steps to bypass this blocker. In any case we need more in-house expertise. No i386 Alpine bindists produced anymore since last release We should deprioritise i386 as GHC is far from being reliable on this platform, and statically linking GHC doesn't work.

Previously: https://hackmd.io/EEI0po6OQtyjGNOVNZx9eQ 3.10.2.0 Release PVP breakage: https://github.com/haskell/cabal/issues/9258This raises the question of keeping the GHC Extensions list inside Cabal. We do not perform sanity checking beyond saying "Unknown extension". Brandon suggests that ghc --supported-languages could be used by Cabal The list was added for the solver tp pick packages, but Mikołaj reports that GHC gets queried at run-time by Cabal. Gershom: long-term we should have a GHC feature with a pragma that declares non-exaustive pattern matches https://doc.rust-lang.org/reference/attributes/type_system.htmlSomething for the Stability WG We postpone the removal of the GHC extensions list for now.

Previously: https://hackmd.io/78RP9BOAQFiq_GM1qNRpYQ Next Release Pre-release binaries for 3.10.2.0 are located at https://gitlab.haskell.org/haskell/cabal/-/pipelines/83511/builds. Most Linux users can use the linux-alpine bindist. HSoC Suganya has submitted the latest PR on the Cabal error codes, this time targeting cabal-install:

Previously: https://hackmd.io/2EPSwwg8QqqZ96cFdW2wTQ Next Release Help needed with #9088.If we can't get it through, we'll skip it for this backport. Cabal exact-printing in HLS HLS has a cabal plugin: https://discourse.haskell.org/t/hsoc-hls-cabal-file-support/7331/2Establishing a context for completions (Value Context, Keyword Context, ...) is not easily possible Custom parsing that works 95% of the time is used. Fitting .cabal intermediate structures would improve the code and reduce maintenance burden for HLS team.

Previously: https://hackmd.io/lTZZevV_RmmeAvIUO1sCKQ 3.10.2.0 patch release Hécate: The pipeline situation seems to have been fixed, as such Mikołaj & I are able to run GitLab pipelines for cabal. I suggest that once the following PRs are merged, the release process (including security fixes) resume. I'd like ideally to be done by next week. https://github.com/haskell/cabal/pull/9088 3.12.1.0 major release Hécate: In accordance with the planned schedule of GHC 9.8, we would like to perform a major release at the end of August. This would be a good idea to highly promote

https://github.com/haskell/cabal/pull/9141 https://github.com/haskell/cabal/pull/9088 Future work wishlist Gershom would like to have an override of cabal.project imports. There are many code paths that are not always entirely lined up. Hécate would like to refactor some of the code paths that live independently of each-other, do the same things, but output different observable results when called the same way. The typical case is one code path living in lib:Cabal, another living in cabal-install, and they could be factorised. Current progress

Basics Basics (mostly done) Most common types (Int, Integer, Char, etc) Functions Syntax and addition where & let…in bindings

Context: https://discourse.haskell.org/t/towards-a-prevalent-alternative-prelude/1986/5?u=kleidukos To start iterating on the base library, we must start by establishing a list of the things we can never break. This list must be at the forefront of each and every one of our efforts. A base library for library developers Getting rid of partial-by-default functions Boolean blindness is bad Parse, don't validate