Google Drive
Gist
Clipboard
Attendance: Mikolaj, Hannes, Brandon, Matthew x 2, Rachel, Francesco, Artem
Nothing to report
Hannes introduces Rachel as working on cabal.project plugin for HLS as part of GSOC.
Release of Cabal 3.16
Introduce a cabal proposal process?
Matthew has proposed the investigation of the idea of a having a proposals process for cabal.
Brandon has some concerns specifically about our organization for this
Brandon & Artem: There should be some escape hatches to avoid making decisions if expertise is not available.
Francesco: Is this process just bureaucracy? What sort of examples might have gone through this process?
Francesco: we need a PR on this proposal.
Only 2 attendees (geekosaur and grayjay), so very abbreviated meeting and no action.
Is the triaging group still active? Can we help them?
f-a will go through all old PR (< 2022) and add the tag propose-closing.
Results of >>Artem: please, consider adding your favorite short/middle-term tickets to the "Considered for 3.16" milestone."<<
cabal upload issue that I added to this milestone earlier. See
propose-closing.hie-bios uses now cabal path, will be shipped with the next HLS release
testlib)Attending: Kristen, Mikolaj
Is it time for cabal 3.14.2 yet?
Is 3.12 (still) the Long-Term Support release?
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
Release manager volunteer for 3.14.2
Deprecation seems more complex issue that we thought: https://github.com/haskell/hackage-server/issues/1345
Should we block the GitHub Merge button for everyone but Admins? (Some discussion in #10714)
Regressions. How are we doing?
https://github.com/haskell/cabal/pull/10524
[This time let's take an action:] Should we block the GitHub Merge button for everyone but Admins? (Some discussion in #10714)
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
Foo.y and Foo.hs, Cabal currently ignores Foo.hs entirely. With this patch, it would ignore Foo.y. Is that OK?PR-welcome.3.14.1.1 release
Regressions in 3.14
packages field of the project file. But no one was able to reproduce it so far…haddock subcommand is confused with sublibraries https://github.com/haskell/cabal/issues/9586; likely not a regressionPhil wants reviews for cabal target: https://github.com/haskell/cabal/pull/9744
Artem really wants the new project file parser to be merged! https://github.com/haskell/cabal/pull/8889
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.)
optparse-applicative? Etc. (Mikołaj mentions logging as another.)3.14.1.0: will there be a post mortem? was there an announcement?
downloads.haskell.org so the release artifacts can be uploaded, then the Hackage candidates will be released and the announcements sent out
(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.
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.OverloadedRecordDot that got blocked by our support window
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….cabal files and add a CI check that forces new extensions to be documented or justified.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.)#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.
cabal-validate: Better output verbosity defaults. +91 -97 lines, pretty straightforward and makes ./validate.sh nicer to use.ghc invocations. +191 −29 lines, comes with tests. Needs review from @mpickering.
#10594, redesigning the PR template
3.12 LTS
Data.Graph). https://paste.tomsmeding.com/QnNIQGrC)cabal format deprecation is blocked by Gershom. What's our way forward?
long-tests
cabal-validate pipeline, lower the count of properties generated#10524: Add dependency provenance information to solver errors
rejecting: memory-0.18.0 (constraint from cabal.project requires ==0.17.0)cabal.project:12 requires ...#9367: Use response files for GHC invocations
--keep-tmp-files, pretty small diff#10562: Tracking issue for cabal-validate devx
cabal-validate output (skip printing config and build plan by default, show build and test output by default)3.14.0.0 API breakage https://github.com/haskell/cabal/issues/10559
3.14.1.0 release: Hécate will start on it ASAP
New regression found in 3.12.1.0: #10504: active-repositories: none fails if ~/.cache/cabal/packages/hackage.haskell.org doesn't exist
cabal update once and then get back to building with active-repositories: none.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:
source-repository-repo: in cabal.project a parse failure
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![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.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.cabal-install 3.14 release, pending
validate.yml sync-pgmJSP, -optJSP?--program-suffixHé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.
cabal format#10457: Default cabal-version could be coordinated with HLS's hls-cabal-plugin support.
cabal init.Food for Kristen: https://github.com/haskell/cabal/issues/10470
(Brandon) #10421 Makefile rule to do local checks
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 insteadMakefile rule that needs to be updated if we want to add it.
validate.sh locally?(Brandon) #10429 debug LTS prereleases
(Rebecca) #10428 add --tasty-arg to validate.sh
./validate.sh --tasty-arg --keep-tmp-files, which makes debugging failed tests much easier.(Rebecca) #10427 Add --pattern arg to cabal-testsuite
./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
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"--keep-temp-files), which itself is blocking #9367 (use response files for GHC arguments).(Brandon) #10372 overnight testing for tier 2 platforms
(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:
fix-whitespace
validate jobValidate post job will catch these and fail the build afterward, I thinkvalidate.sh to Haskell, add more flexible test filteringtestConfigOptionComments--keep-temp-files options between subcommands
system-filepath won't install with ghc 8.0
custom-setupCabal release (here checklist)
custom-setup's problems).
LANGUAGE additions now, option additions by first alphacabal-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)
io-classes workaround will go in
Past meetings were kept in individual notes, with back-links to earlier meetings. The last such is here.
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe