Cabal meeting notes 2024-09-12 - 2025-09-25

Newer meeting notes: https://hackmd.io/ytXS6xrAS2mTyPVxdUS6OA?both --- # Cabal meeting (2025-09-25) ## Attendees Mikołaj, Brandon, Kristen, Francesco, Artem ## Previous meeting wrap-up - Done: Warn developers not to use SMS 2FA. I have sent messages/emails and received confirmation that each dev is not using or stopped using SMS as 2FA. (f-a) - (f-a) `cabal-proposals`: last time I urged this meeting to accept the “Support for bytecode files and libraries” proposal. That was as mistake on my part! Moritz Angermann [complained](https://github.com/haskell/cabal-proposals/pull/2#issuecomment-3283743562) in the thread and further discussion ensued. I should have waited for Matthew to return from vacation before calling a vote, apologies for the mess. The proposal is open again. - Repair GitLab pipeline: I have informed Chreekat about the dev consensus (that is: if possible, have a backup pipeline for next release). He seemed happy with it. (f-a) ## Current affairs - (maerwald) take note/discuss https://github.com/haskell/cabal/issues/11224 * noted; thank you * this looks well reproduced/researched * we'd very much like to have a second look when the GHC part is more or less concluded and a cabal PR is submitted * Julian: would you like us to have a closer look at any particular question/proposal/alternative in the ticket? ## Review needed - [2 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## Food for thought - Mikolaj to Artem: I'm wondering if we could maybe move the meeting by 0.5h till December to make sure we don't finish before you join; I could be there at the sharp hour and entertain any early joiners until you come or maybe we could go through PRs or issues during the first half or something? * The decision is to go through PRs and tickets during the next meeting (2025-10-09) and keep only Mikolaj on guard (doing the PRs and tickets with whomever joins unaware of the change) starting on the meeting a month from now (2025-10-23), and everybody joins at half past from then on, till December. # Cabal meeting (2025-09-11) ## Attendees Francesco, Mikołaj, Kristen, Brandon, Artem. ## Previous meeting wrap-up - "The CLC wants a list of official maintainers / contacts (#11193)" - partly addressed in https://github.com/haskell/cabal/pull/11195 (merged) by adding - https://github.com/haskell/cabal/blob/master/MAINTAINERS.md - it defines Cabal maintainer as someone who participates in releasing cabal on regular basis - second/third part of it (not yet addressed) is cleanup of Hackage uploaders and Cabal GitHub Admins. - Artem proposed to sync those with MAINTAINERS.md - Brandon and Francesco agreed - Artem wants a nod from Mikolaj - Maybe we should add a CLC rep to Hackage/GitHub admins? - Julian says this is unnecessary (see ticket) - Artem: says that we need to trim both lists. But GitHub is trickier! - Mikołaj: there is also Haskell organisation, which has authority over us (on GitHub), so we have _a lot_ of people with permissions on the repo. - Francesco: Hackage seems uncontorversial, so we can do it first. - Brandon: see point below about Open Source Collective PSA. - There are ways to grant specific permissions without giving too much power (e.g.: labels). - we need to revisit a decision we made last year w/r/t override merge button). - Mikołaj: we should thank old maintainers and send them a message! - **action:** prune Hackage & send email to old maintainers (Artem). Research GitHub permissions (Brandon) - cabal logo: (f-a) [waiting for SVGs](https://github.com/haskell/cabal/pull/11169). - **action**: well, wait and poke (Francesco). - GitHub Secure Open Source Fund. f-a looked at some tickets which might be of interest to whoever wants to submit a proposal: - [Name security in additional package repositories](https://github.com/haskell/cabal/issues/8502). - [Split out TUF](https://github.com/haskell/hackage-security/issues/249). - [Perform additional cheap integrity checks as part of checkForUpdates](https://github.com/haskell/hackage-security/issues/199). - [checkForUpdates interacts badly with the CDN](https://github.com/haskell/hackage-security/issues/106). - [Extend MetadataEntry with signatures](https://github.com/haskell/hackage-security/issues/86). - And a dump of todos (`lentil ~/media/vcs/hackage-security/ > /tmp/errors.txt`) [here](https://paste.debian.net/hidden/439a93e7/). - The documentation in `hackage-security` is there, but it is a bit stale. There are mentions of “Phase 1” and “Phase 2”, but the latter Phase was abandoned. Some issues are also very vague (like [this one on automated testing](https://github.com/haskell/hackage-security/issues/67)). - Mikolaj says: We could ask Duncan and Edsko to sketch "the remaining part of TUF/Phase 2" that is missing, mostly package authors signing their packages from what I understand. But Phase 2 is a much larger undertaking than the 3-week small projects that are funded. Maybe creating, disseminatnig, discussing, amending a plan for Phase 2 could be funded with that? But this may be premature. Related links: - https://www.well-typed.com/blog/2015/07/hackage-security-alpha/ https://www.well-typed.com/blog/2015/08/hackage-security-beta/ https://www.well-typed.com/blog/2016/09/hackage-reliability-via-mirroring/ https://github.com/haskell/hackage-security/milestone/4 - It would be nice to know for Hackage to show signed package. ## Current affairs - The Open Source Collective recently put out a [PSA](https://opencollective.com/opensource/updates/public-service-announcement-re-salt-typhoon) about supply chain attacks in widely used FLOSS software - it is admittedly from the US, which makes it somewhat dubious, but the recommendations would equally apply to them as a state actor so I think this is on the level - relevance to us: - there is a certain belief that Haskell is more secure than other languages (see for example the brouhaha over Safe Haskell and what it does and doesn't do), which may make us a target for supply chain attacks - review access to GitHub and Hackage, keeping the recent LZMA exploit firmly in mind - make sure everyone is using MFA _not dependent on SMS_ and ssh to push. Ideally also GPG-signed. - this is one of the things that makes me think it's legit, as it's an open secret that the FBI already sees everything on US cellular networks and the US as state actor would want to keep it that way - this applies also to non-US contributors and admins, as GitHub's servers are in the US - review our own supply chain (external GitHub actions, mostly, but we do install a few extra programs (hackage-security, changelog-d, hlint, etc.)) - sadly there is little to be done about GitHub itself as potential vector, as we're not in a position to audit runners or the images they install - it is possible that we might need to consider a full source code audit, but as we *should* be seeing everything going into it anyway this might not be urgent - in light of the above "should be", possibly revisit the decision to allow manual merges and/or direct commits to non-admins - note that Mergify is already on an exception list that allows it to merge things - our supply chain also includes GHC and multiple bootlibs - I relayed above link to the HF's Matrix channel; no response yet - ideally the HF would coordinate similar supply chain and access reviews for bootlibs and other core ecosystems (stack, aeson, conduit, lens, etc.). - **action**: - warn developers not to use SMS 2fa (Francesco). - Brandon will review GitHub actions we rely on. - (f-a) Cabal proposal: [Support for bytecode files and libraries](https://github.com/haskell/cabal-proposals/pull/2). - opened two weeks ago, we should decide whether to extend the discussion period, accept it — only if we deem consensus was reached! Let us decide know whom to ping (people who are interested in the topic / people who might be unhappy with possible implementations / people who are going to review the PR). - **action**: no objections, accepted! (Artem notes that there was a Discourse thread on the proposal). - (chreekat, not attending) RFC: Repairing GitLab pipelines - Background: Release CI has been implemented on GitHub, but my working assumption is that the previous Git*Lab* CI will still be used for minor releases of 3.16 to ensure no breaking changes regarding platform availability. - Situation: GitLab CI (may it soon RIP) is failing and will take a hot minute to fix again 1. An eager reaping process removed all the Docker images used by CI (I think? Ben Gamari may know). 2. The images can't be regenerated from the [same commit](https://gitlab.haskell.org/ghc/ci-images/-/pipelines/110688), because `apt-get update` fails during the run. 3. The easiest workaround—using the [latest commit](https://gitlab.haskell.org/ghc/ci-images/-/pipelines/114988)—would force a change in platforms, albeit not much of one. - Desired outcome: Decision on which step to take: - Option 1: Declare GitLab bankruptcy and give up. Go whole-hog on the new GitHub CI, platform availability be damned. - Option 2: Accept some minor change in platform availability. The list would be: - i386-alpine3_20 *replaced by* i386-alpine3_22 - x86_64-alpine3_20 *replaced by* x86_64-alpine3_22 - aarch64-alpine3_18 *replaced by* aarch64-alpine3_22 *Optimistic pipeline attempt: https://gitlab.haskell.org/haskell/cabal/-/pipelines/115078/* - Option 3: Something else that I realistically don't have time for and probably nobody else does, either. - (One of these seems best to me, guess which one) - Discussion: Brandon fancies Option 1, since the alternatives are not worth the effort. Artem: try to migrate to GitHub at next major release would be better, but I would not object to a complete severance now. Mikołaj agrees we would be great to have a backup - Note that 3.16 may have a long lifetime, as the GHC team has declared GHC 9.14 to be an LTS release. - **action**: if it is possible and takes not that much time, we would like to have a backup for th enext releasee so that we are not saddle sif something on th enew CI breaks. Relay this to Cheekrat (Francesco). ## Review needed - Artem: pretty please, review/approve the GHC 9.14-alpha CI bump: https://github.com/haskell/cabal/pull/11174 it's mostly trivial. - [4 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## Food for thought # Cabal meeting (2025-08-28) ## Attendees * Francesco * Brandon * Kristen ## Previous meeting wrap-up * GitHub Open source secure fund: still no volunteer, Francesco is looking into it from a personal point of view. * Cabal logo: Francesco asked fgaz to provide a vector logo, we will have to wait a bit becuase it might be in another hard disk. * [Julian does not want to work on reducing the number of binaries anymore](https://github.com/haskell/cabal/pull/11083#issuecomment-3194884604). * Brandon says there is no chance to have it in 3.16 now, as it is final, so obviously 3.18 is the earliest we can get this in. The work is already there, there is nothing to be done. ## Current affairs * The GHC 9.14 PR ([#11174](https://github.com/haskell/cabal/pull/11174#issuecomment-3221327158)) is currently stuck on a failing test that needs to be rewritten * **Brandon** will try to work on it today after the meeting * The CLC wants a list of official maintainers / contacts ([#11193](https://github.com/haskell/cabal/issues/11193)) * Brandon: this is a social problem, not strictly technical. We need someone socially apt to be CLCs point of contact. * Francesco and Brandon: we would need to do a cleanup of uploaders too. And for the GitHub repo. * Brandon: we need to be careful because permissions were given for a reason. E.g. myself are maintaining Matrix intergration and I need to be an admin for that. * actions: * weed the maintainers lists for both Hackage and the GitHub repo * propose someone for the CLC point of contact * **Francesco** will write about this in Matrix, considering that this is an internal issue that we need to deal with by ourselves. (Artem volounteered for the list!) * New Cabal Proposal: [Cabal Support for Bytecode Objects and Bytecode Libraries](https://github.com/haskell/cabal-proposals/blob/wip/bytecode-options/proposals/bytecode-files.md). * **Brandon** will ping relevant developers in the ticket. * Cabal logo: see above. ## Review needed - [8 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## Food for thought # 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](https://github.com/haskell/cabal/pull/11135#issuecomment-3164394538), 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 - [7 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## Food for thought - Delay [the "only two release artifacts" PR](https://github.com/haskell/cabal/pull/11083) until the next major release; someone else will probably have to take it over the finish line - https://github.com/haskell/cabal/pull/11072#issuecomment-3175334179 we may need a socially competent person to mediate that kind of situation in the future # Cabal meeting (2025-07-31) ## Previous meeting wrap-up - Release success. 2 regressions so far - REPL: `cabal repl` silently fails, in, seemingly, two different ways depending on in-project vs. out-of-project - cabal repl (3.16.0.0) silently fails: https://github.com/haskell/cabal/issues/11107 - PR: https://github.com/haskell/cabal/pull/10684 it may fix a part of the problem or the whole problem - HLS incompat: there's a matrix of incompatibilities - HLS HEAD isn't compatible with ??? but that's a rare enough config, hopefully - another incompat: older HLSs (which people with older GHC are bound to) won't work with cabal 3.16 and next ones - 3.16.0.0 post-mortem notes: https://hackmd.io/2zNfXN8NT9qoqdHuWEeSdw - 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 * Actually, did we formally acknowledge the results of the logo poll? https://discourse.haskell.org/t/final-poll-for-a-new-cabal-logo/12252 * we do so now, gratefully; Francesco is going to engage the participants of the poll and invite them to offer a PR that changes the logo * "repo/root.json does not have enough signatures signed with the appropriate keys (cabal-install < 3.10.2)" https://github.com/haskell/cabal/issues/11111 * not clear if it's "us" or "them" who could have prevented this * hackage-server made an update that broke our old clients * there're discussions in many places * PR trying to fix it: https://github.com/haskell-infra/hackage-root-keys/pull/24 ## Review needed - [9 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## 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 * Julian's CI rewrite: https://github.com/haskell/cabal/pull/11072 - [10 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## 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](https://github.com/haskell/cabal/issues/11010) * 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 - [12 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## 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](https://hackmd.io/X62yS0d6RxW3ybh8AmRqlw?both#Cabal-meeting-2025-05-22).) - 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 - [8 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) - https://github.com/haskell/cabal/pull/9871 ## 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 - Bodigrim says <<To be precise, I can run a month-long Discourse poll to choose between top two contenders at https://discourse.haskell.org/t/poll-for-new-cabal-logo/3287, namely "@JonathanLorimer’s design 1" and "@fgaz’s design".>> in https://github.com/haskell/cabal/pull/7432#issuecomment-2923410351, so let's decide. * We'd like to instead as for a poll with 3 options: the two and the old logo, if that's not too cumbersoome. I will let Bodigrim know. - Let's not forget about triaging (discussed somewhere below). Maybe let's look at the needs_triage issues next time. ## Review needed - [13 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## 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 - Is the triaging group still active? Can we help them? - Let's ask Hecate and Artem about https://www.codetriage.com/haskell/cabal?issues_before=1125385039#help-out - f-a will go through all old PR (< 2022) and add the tag `propose-closing`. ## 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 - [11 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## Food for thought # Cabal meeting (2025-05-08) ## Previous meeting wrap-up - Results of >>Artem: please, consider adding your favorite short/middle-term tickets to the ["Considered for 3.16"](https://github.com/haskell/cabal/milestone/65) milestone."<< - Artem: I don't see any. I'm still working on the "chatty" issue https://github.com/haskell/cabal/issues/10885, draft is here: https://github.com/haskell/cabal/pull/10940/ - There's a splash of activity from Andreas Abel about the `cabal upload` issue that I added to this milestone earlier. See - https://github.com/haskell/cabal/issues/10920 - https://github.com/haskell/hackage-server/issues/1389 ## 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 - [11 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## Food for thought # Cabal meeting (2025-04-24) ## Previous meeting wrap-up - Opinions on [#10900](https://github.com/haskell/cabal/issues/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 - [13 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## Food for thought - Artem: please, consider adding your favorite short/middle-term tickets to the ["Considered for 3.16"](https://github.com/haskell/cabal/milestone/65) 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 * Mat asks to review PRs * Javier: Opinions on https://github.com/haskell/cabal/issues/10900 (New stanza `testlib`) ## Review needed #### [16 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## Food for thought # Cabal meeting (2025-03-27) Attending: Kristen, Mikolaj ## Previous meeting wrap-up - Is it time for cabal 3.14.2 yet? * it seem people want the new release rather badly (https://github.com/haskell/cabal/issues/10836) and also almost all PRs for regressions are merged, so it seems it's about time - Is 3.12 (still) the Long-Term Support release? * we don't know yet - 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 * Mikolaj will ask around at Well-Typed * Kristen will open a separate ticket at hackage-server * https://github.com/haskell/hackage-server/issues/1374 ## Current affairs - Release manager volunteer for 3.14.2 - Mikolaj volunteers in emergency; Kristen accepts - Deprecation seems more complex issue that we thought: https://github.com/haskell/hackage-server/issues/1345 ## Review needed #### [16 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## 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](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## 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](https://github.com/haskell/cabal/pull/10714#issuecomment-2585586765)) - 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](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## 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](https://github.com/haskell/cabal/pull/10714#issuecomment-2585586765)) - YES (no objections) - If no more objections till next chat, let's do it at the next meeting. - Mikolaj will do offline ## Current affairs - Regressions. How are we doing? - We have at least 6 regressions and at least 4 fixed regression. We'd love to make a point release with the 4, but the 6 would be better be fixed before that. We need fixes and reviews: https://github.com/haskell/cabal/issues?q=is%3Aissue%20state%3Aopen%20%20label%3A%22regression%20in%203.14%22 - https://github.com/haskell/cabal/pull/10524 - (action: f-a) Let's recomment splitting up PRs, in particular, limiting them to what's on the tin, e.g., a bugfix exclusively, or a single feature. Let's write it down in CONTRIBUTING.md. ## Review needed #### [18 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## 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](https://github.com/haskell/cabal/pull/10714#issuecomment-2585586765)) - YES (no objections) - If no more objections till next chat, let's do it at the next meeting. ## Current affairs - a regression: https://github.com/haskell/cabal/issues/10686 - an old but annoying bug; any ideas? https://github.com/haskell/cabal/issues/10252 - 9999years: can we destroy the `cabal-head` tag btw? it should be a branch, every `git pull --tags` invocation fails unless you delete the `cabal-head` tag first - Artem: I don't see a problem with killing cabal-head after creating the release. We must check that this doesn't screw the release. ## Review needed - [#10534: Improve preprocessing performance](https://github.com/haskell/cabal/pull/10534#discussion_r1854788325) - This _technically_ changes behavior: if you have `Foo.y` and `Foo.hs`, Cabal currently ignores `Foo.hs` entirely. With this patch, it would ignore `Foo.y`. Is that OK? #### [16 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## 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](https://github.com/haskell/cabal/pull/10714#issuecomment-2585586765)) - Could we agree to this transition away from lukko [#10724](https://github.com/haskell/cabal/issues/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](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) - 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](https://github.com/haskell/cabal/wiki/Making-a-release#a1-before-the-release)) - 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](https://github.com/haskell/cabal/issues/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 - Phil wants reviews for `cabal target`: https://github.com/haskell/cabal/pull/9744 - Andrea asked for changes in the past, and Phil claims he applied them. So, it'd be great if Andrea could check. - Artem really wants the new project file parser to be merged! https://github.com/haskell/cabal/pull/8889 - Should we hide it behind an "experimental" flag?.. - Since it's been extensively tested, maybe not. But generally it's a cool idea. - [#10491: Autoformat more directories](https://github.com/haskell/cabal/pull/10491) #### [~~17~~ 16 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) (down ~~1~~ 2 from previous meeting) ## Food for thought # Cabal meeting (2024-12-19) ## Previous meeting wrap-up ## Current affairs * 3.14.1 release --- is any help still needed, or is an announcement up already? * release notes could still use re-reviews and additions (don't wait for Hecate to opine, just do whatever you think is needed and ping Hecate afterwards): https://hackmd.io/jEZNhFoNRGGN1nNQxf2QzA * Hécate: PR up for fixes to the ghcup metadata generation script: https://github.com/haskell/cabal/pull/10643 ## Review needed #### [18 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) --- # 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](https://github.com/haskell/cabal/pull/10554/files#diff-70b9c726d883546be464ea65b32e9512bb4de729172b055401dbbc95202285a0R1-R4)), 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](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/issues/10605): Recent work on shallow clones for `source-repository-package` broke some invocations with abbreviated or non-canonical refs, which cannot be `git fetch`ed 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](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) - [#10573](https://github.com/haskell/cabal/pull/10573): `cabal-validate`: Better output verbosity defaults. +91 -97 lines, pretty straightforward and makes `./validate.sh` nicer to use. - [#9367](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/pull/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? - https://github.com/haskell/cabal/pull/10469 - resolved in https://github.com/haskell/cabal/pull/10549 - We had intended to "test drive" Hécate's deprecation policy with this, but now we can't - RFC on Discourse, Haskell-Cafe, etc. - Also mention in announcement for 3.14.1.0 maybe? - Probably doesn't belong in release notes until it's official - 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](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) - [#10524](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/issues/10562): Tracking issue for `cabal-validate` devx - I have a bunch of ideas to discuss here :) - [#10573](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/issues/10504): `active-repositories: none` fails if `~/.cache/cabal/packages/hackage.haskell.org` doesn't exist - Can fix it with a partial revert of [#8944](https://github.com/haskell/cabal/pull/8944) (see [#10506](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/pull/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. - See https://mail.haskell.org/pipermail/cabal-devel/2024-October/010588.html - Hécate: it should cover all libraries in the cabal repository that we publish - No objections to gratefully agree to the proposal. Who'd respond to CLC? [Mikolaj did.] - Set of backports for 3.14.1 that need approval: - [x] remove hashable dependency: https://github.com/haskell/cabal/pull/10536 - [x] Print out which project file we're using: https://github.com/haskell/cabal/pull/10535 ## Review needed #### [21 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) - [#10525](https://github.com/haskell/cabal/pull/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. * (Rodrigo) Concurrent and shallow git cloning https://github.com/haskell/cabal/pull/10254 ## 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](https://github.com/haskell/cabal/issues/10263#issuecomment-2444669823)). * 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 * [x] Cabal 3.14 release redux still pending * 31st of October * [x] We still don't have tags for the 3.14 release * Hécate: Done. https://github.com/haskell/cabal/releases/tag/Cabal-3.14.0.0 and https://github.com/haskell/cabal/releases/tag/Cabal-syntax-3.14.0.0 ## Current affairs * cabal-install 3.14 release, pending * [#10459](https://github.com/haskell/cabal/pull/10459) `validate.yml` sync * [#10468](https://github.com/haskell/cabal/pull/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](https://gitlab.haskell.org/ghc/ghc/-/issues/25397) 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](https://github.com/haskell/cabal/pulls?q=is%3Aopen+is%3Apr+label%3A%22attention%3A+needs-backport+3.14%22) * [#10290: a regression from 3.12 with `--program-suffix`](https://github.com/haskell/cabal/issues/10290) * 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](https://github.com/haskell/cabal/pull/10448) ensure sdist test runs on the correct ghcs #### [23 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## Food for thought * [#10457](https://github.com/haskell/cabal/issues/10457): Default `cabal-version` could be coordinated with HLS's `hls-cabal-plugin` support. * Prior art: https://github.com/haskell/cabal/pull/8978 * HLS team will send us PRs to change the suggested cabal-version in `cabal init`. * Food for Kristen: https://github.com/haskell/cabal/issues/10470 --- # 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](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/pull/10421) `Makefile` rule to do local checks * This rounds out answering Matt Pickering's round-tripping complaint [#10263](https://github.com/haskell/cabal/issues/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](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/pull/10292) (expand and unify `--keep-temp-files`), which itself is blocking [#9367](https://github.com/haskell/cabal/pull/9367) (use response files for GHC arguments). #### [21 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) * (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](https://github.com/haskell/cabal/pull/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](https://hackmd.io/c/codimd-documentation/%2F%40codimd%2Funderstanding-your-editor). 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](https://github.com/haskell/cabal/pull/10376) (Brandon) Makefile targets for `fix-whitespace` * Javier asks whether it takes care of CRLF, is this enabled in our repo? * [#10363](https://github.com/haskell/cabal/pull/10363) (Brandon) switch back to Apple AArch64 builder * Mac jobs are only a couple minutes slower than Ubuntu! * [#10372](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/pull/10273) (9999years) show why configuring dependencies failed * helps debug nix (and other build system?) failures * [#10320](https://github.com/haskell/cabal/pull/10320) (9999years) convert `validate.sh` to Haskell, add more flexible test filtering * [#10314](https://github.com/haskell/cabal/pull/10314) (9999years) improve assertion messages for `testConfigOptionComments` * [#10292](https://github.com/haskell/cabal/pull/10292) (9999years) unify multiple `--keep-temp-files` options between subcommands * blocker for [#9367](https://github.com/haskell/cabal/pull/9367) * [#10366](https://github.com/haskell/cabal/pull/10366) (jasagredo) create temp files in temp directory (Higher relevance for Windows users) #### [26 PRs have the "attention: needs-review" label](https://github.com/haskell/cabal/labels/attention%3A%20needs-review) ## Food for thought  * [#10379](https://github.com/haskell/cabal/issues/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](https://github.com/haskell/cabal/issues/10241)) - [#10336](https://github.com/haskell/cabal/pull/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](https://github.com/haskell/cabal/issues/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](https://hackmd.io/0rbgncjjR8qk8To6uzfGpQ?both).

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.