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
This allows HOMEBREW_INSTALL_FROM_API functionality to be disabled and will stick around once
HOMEBREW_INSTALL_FROM_API is made the default behaviour.
Co-authored-by: Eric Knibbe <enk3@outlook.com>
This doesn't need to be nearly as often for HOMEBREW_INSTALL_FROM_API users because we're getting the latest information from the API when needed rather than just at `brew update` time.
