<div dir="ltr">## Current affairs<br><br>    3.10.3: are we missing anything else? Does Julian want anything else?<br>        [Covered: Hecate volunteers] Mikolaj asks humbly: Could somebody ask Julian?<br>        [Done: approved for 3.10.3, Javier handled the backport, merged.] This is the only apparent non-merged candidate PR (conditionally recommended by grayjay): <a href="https://github.com/haskell/cabal/pull/9550">https://github.com/haskell/cabal/pull/9550</a><br>        [MK: Now merged.] #9525 should be merged too, bot got stuck? —F<br>        We’ve agreed to release ASAP and not to block the release on anything else, any backports, etc.<br><br>    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:<br>        Extend user-config, it’s just annoying™ (-- Fendor)<br>        Make path aware of cabal projects, and unify path and status with user-specified outputs and format to ensure backwards compatibility, and add the ghc location as part of the possible outputs. (-- Fendor)<br>            Merging the two commands has direct benefits for HLS such as:<br>                Improved start-up times for cabal projects<br>                Improved time until diagnostics are displayed to the user<br>                Inform users about project issues (e.g., no build plan) in the UI<br>                Fewer hacks to find the compilations options given a FilePath<br>            Merging the two commands should be rather straight forward:<br>                Rename #7500 cabal status to cabal v2-path (Only to disambiguate from current cabal path in this context). Maybe a new PR would be good: #7500 is overloaded with old conversations. Also, rebasing #7500 looks like a major undertaking.<br>                    Some other ideas for the name of that command: cabal info (Javier), cabal query (Mike).<br>                Copy flags of current cabal path to cabal v2-path<br>                Remove resolving FilePath’s to Unit-ids from cabal v2-path<br>                Review and Merge :)<br><br>    A PR author would benefit from a clarification about our (unwritten? if written, link?) policy for “guarding behind cabal-version”: <a href="https://github.com/haskell/cabal/pull/9535#issuecomment-1866354715">https://github.com/haskell/cabal/pull/9535#issuecomment-1866354715</a><br><br>        We must chat with the GHC developers to reflect GHC’s reality, see why cabal has a list of architectures, a list of aliases and GHC has a different list. We must reconcile the three. Rodrigo: I think the “canonical” definition should be ghc-platform (previously in ghc-boot), as it is an independent package that exposes ArchOS data type that is used by ghc and ghc-toolchain.<br><br>        Should write down somewhere the policy for guarding behind. It has come up several times recently. For example: this applies only to .cabal files, not to cabal.project files. Please volunteer and sign up in <a href="https://github.com/haskell/cabal/issues/9552">https://github.com/haskell/cabal/issues/9552</a><br><br>    The STF funding has just now been granted to Well-Typed for the second 4-month term of cabal work (including a bit for maintenance work)<br>        Hécate: This is not only to implement <a href="https://github.com/haskellfoundation/tech-proposals/pull/60">https://github.com/haskellfoundation/tech-proposals/pull/60</a>?<br>        Rodrigo: Not it isn’t. Mainly, we intend to build upon the work done there by improving cabal-install accordingly.<br><br>## Review needed<br><br>    @Jasagredo #9527: I was mostly guided by what arguments were already there and where I could get the extra paths from. Having someone more familiar with how arguments are passed at different levels taking a look would be super nice. And in general I think this PR is a big QoL improvement on Windows. Could even benefit from backporting to 3.10 if we want to, otherwise, it is not urgent.<br>        It is agreed this shall not block the 3.10.3.0 release, but if it arrives in time, then it would be fine.<br><br>    A closure to the “PackageInfo not guarded behind cabal-version story”: <a href="https://github.com/haskell/cabal/pull/9525">https://github.com/haskell/cabal/pull/9525</a> (unless somebody can spot anything we missed)<br><br>    Rodrigo:<br>        Update changelog for per-component with coverage #9542<br>        Account for .buildinfo in repl when build-type: Configure #9440 (fixes #9401)<br>        Refactor ProjectBuilding into Package Phases #9524, Andrea said he’d look too.<br><br>    curl errors in CI: #9530 (with a link to a PR that possibly fixes it inside) It looks pretty disturbing to devX. <meta: putting here for visibility>. Also occurring in #9542<br><br>## Food for thought<br><br>    Have we settled the revisions controversy yet? (The urgent part is settled, I think)<br>        the concrete case is almost settled, but let’s discuss (<a href="https://github.com/haskell/cabal/pull/9523#issuecomment-1866082009">https://github.com/haskell/cabal/pull/9523#issuecomment-1866082009</a>)<br>        the general policy still lacks our preference for prerequisites for revisions (e.g., a build or a test run, <a href="https://github.com/haskell/cabal/issues/9531#issuecomment-1859994178">https://github.com/haskell/cabal/issues/9531#issuecomment-1859994178</a>)<br><br>    Hecate: please use cabal-head (see the README on how to get it), and if possible, file PRs to <a href="https://github.com/haskellfoundation/error-message-index">https://github.com/haskellfoundation/error-message-index</a> with the Cabal errors. There are none documented yet!<br><br>And lest we forget<br><br><span style="font-family:monospace"> _________________________________<br>/ Happy Christmas (or appropriate \<br>\ festivity) everyone!            /<br> ---------------------------------<br>        \   ^__^<br>         \  (oo)\_______<br>            (__)\       )\/\<br>                ||----w |<br>                ||     || -ffaf1<br></span><br><br></div>