# Cabal meeting (18/01/2024)

Previous meeting notes at: https://hackmd.io/UsYDbySERP2SWfE7jRRdqg

## Current affairs
<!--
Outstanding things on which we have to adjudicate.
Important, of various degrees of urgency
-->

* 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.
- Mikolaj's TODO: write down the job description as discussed.
- Conclusion: Expand the PR template to include a section/checkbox for "This is a CI fix and will need to be backported" (or something along those lines). Francesco A. volunteered.

* Mikolaj: Do we want to re-organize our release management (in time for 3.12 that HLS users are likely to clamour about RSN) so that the releases are less of a lone hero epic battle and more a coordinated team effort, e.g., with the release manager being strictly a coordinator only?
Artem: we need a gradual transition, not a one-night revolution. That could go via release process being more distributed in nature. Someone familiar with the process should think what **sub-tasks** can be dispatched to volunteers. I personally would love to pick up some of those.
- Unless there are objections, we'd try the most extreme variant, the purely-managerial release manager role for 3.12 and we'd see how it goes.
- Proposal: Port GHC's check for programatically know when something was a breaking change on the API

* Francesco² ([#9621](https://github.com/haskell/cabal/pull/9621#discussion_r1455253267)): `cabal check` warning again about missing `default-language`. Should this be guarded (i.e. when `cabal-version` is at least 3.11)?
(long story short: GHC is introducing *language editions*, packages that do not specify `default-language` may be broken when GHC default changes. Adam Gundry asked us to warn the user when `default-language` is not specified.)
actions:
- update documentation if necessary (Francesco);
- see if the PR is still needed (Francesco).

Remark (Andreas): since omitting default-language means defaulting to Haskell98, this feature seems rather useless to me. I'd vote for making default-language mandatory again in the next version of Cabal files (cabal-version: 3.12).

* Artem: any chance to get more opinions on a PR strictly related to Cabal maintenance as a software project, restructuring the project files: https://github.com/haskell/cabal/pull/9565
- The reception is positive. Let's move forward.

## Review needed
<!--
We need to take a look at these PRs and help them move on.
Urgent, of various levels of importance
-->

* Javier: Some of the review needed PRs are in an uncertain state. Some changes were requested or proposed but it is unclear if the PR is still ready to review (as an example [this one](https://github.com/haskell/cabal/pull/9521)). Should the `attention: needs-review` label be removed in these cases? If so, it is probably responsibility of the author to do so?
* Be generous send cheerful and encouraging status check messages to those PRs
* TODO: We can make this relationship (review_needed, draft, none) explicit, Mikołaj. Your explanation is worth putting in the wiki.

* Rodrigo: Refactor the core component building logic: gbuild vs buildOrReplLib [#9602](https://github.com/haskell/cabal/pull/9602). It is 99% done, ready to be reviewed.
* Have tested the refactor extensively by logging all GHC invocations when compiling the testsuite, and diffing them against cabal-HEAD, guaranteeing the refactor doesn't change any current behaviour.
* Unblocks many bug fixes and improvements, making some things, that were hard, low hanging fruit.
* Lots of "ROMES:TODO:" comments that I will pick up in a subsequent MR.

## Food for thought
<!--
We want to start the thinking process amongst ourselves for things that will take time to unfold.
May be important, but not urgent
-->

* Javier: Tweaked the [`default-package-bounds` PR](https://github.com/haskell/cabal/pull/9570). Unqualified bounds (`foo >2`) apply to `build-depends`, qualified bounds (`foo:bar >2`) apply to `build-tool-depends`. Sounds good? In particular it disallows constraints for sublibs directly, one has to constraint the full package (which makes sense but maybe is not that obvious?). If OK then what are the next steps for getting this to main? (P.S. I've been dogfooding it and it works on my machine :tm:)
- Gershom raised his concern about this being done in the solver. Discussion will continue in the PR.

* Rodrigo: [#9618](https://github.com/haskell/cabal/pull/9618) has been approved (which I picked up from #9326). >= ghc-9.8 has an ABI hash, which we now use in package hashes and dir-layout to avoid mixing ABI-incompatible GHC's.

* Rodrigo: Maybe we don't need a test for https://github.com/haskell/cabal/pull/9470