These PRs were all approved by the majority of the PLC and the majority
of them approved by the majority of the TSC. They are being put here for
a members vote, ideally before the AGM.
- Replace some "Owners" with "billing managers" and "moderators"
- Now that GitHub has more granular roles available such as "billing
managers" and "moderators": let's tighten up our security posture by
only have 3 folks who need to be "Owners" rather than 10.
- Max two PLC terms
- We discussed this one year terms last year but this seems a better
solution. Given we refresh maintainers, TSC and the Project Leader
yearly: this seems more consistent, responsive and fair. Note this
would only apply to candidates for the PLC from 2024.
- Tweak nomination rules
- Do not require any nomination: any member can run for the PLC. This
simplifies the procedure: no nomination vote has to be done inside
the old PLC. Members do not need to go and find someone to sponsor
them. Just apply and let the vote begin. Ask to write down the
intentions and keep a candidate list by using a Slack channel, to
keep track of everything
- Mandate that the PLC report their activities
- Mandating that the PLC report back their actions throughout the
year. The wording here is intentionally strong - I feel it is very
important for the health of the PLC and the membership for this to
be stuck to.
- Don't need financial statements, have OpenCollective
- Now that we have an open, publicly readable ledger of all our
financial transactions: there does not seem to be any need to
continue to have the PLC re-publish reports of our finances
(which were hidden to all but the PLC in our SFC days).
- Make maintainer removal more explicit.
- Improve this guidelines to provide more evidence for why, what and
how this process occurs
- Allow maintainers to appeal the decision of the project leader
- Allow the project leader to re-request this vote if no progress is
made
- Clarifies maintainer nomination process language/formatting
When either being in a non-default prefix or being on an unsupported
macOS version we expect most things to be built from source. In that
environment, do not allow HOMEBREW_INSTALL_FROM_API to be set.
Fixes#14475
- For the command `brew install --cask racket`, a user was reporting the
behaviour where despite `--cask` in the command, they were getting
output about the `racket` formula having been renamed:
```
$ brew install --cask racket
Warning: Use minimal-racket instead of deprecated racket
==> Downloading https://mirror.racket-lang.org/installers/8.7/racket-8.7-x86_64-macosx-cs.
==> Installing Cask racket
[...]
racket was successfully installed!
```
- The "instead of deprecated ..." messaging comes from the `TapLoader`
class `formula_name_path` method, so _something_ must be assuming
that everything is initially a formula before _later_ learning from
further args parsing that there's a `--cask` qualifier to scope to
only casks.
- There are always `@formula_options` and args parsing is recursive,
going through each option, so we check that the original `argv` items
include a `--cask` and skip calling the `formulae` method if that's
the case.
- After this change, the "formula renames" words no longer show up.
```
$ brew install --cask racket
==> Downloading https://mirror.racket-lang.org/installers/8.7/racket-8.7-aarch64-macosx-cs.dmg
==> Installing Cask racket
[...]
racket was successfully installed!
```
