Re: git: e2650af157bc - main - Make CPU_SET macros compliant with other implementations

Some time ago I started a best practises doc for potentially
disruptive src changes (and have received some feedback, including
from folks on this thread). I'll paste it here for further discussion.
---
This is the suggested process for introducing tool chain and other
changes in the src tree that may cause significant disruption to
ports. Some examples of potentially disruptive changes are:

- major compiler updates
- OpenSSL updates
- adding a library or system call (such as memfd) that is already
present on other systems
- changing the semantics or APIs of existing libraries

The goal of this document is not to be overly prescriptive, but to
document a process that has produced good results in the past, avoid
surprises among ports committers and maintainers, and clarify the
expectation on port maintainers to collaborate on addressing fallout
from the potentially disruptive change. The project gets the best
results when everybody works together, in good faith, to solve
problems with disruptive changes.

Disruptive change process:

1. Request a ports exp-run with the desired change. This is used to
determine the initial impact of the change. If the exp-run shows no
impact or minimal impact the rest of the process may be skipped.

2. Verify that important packages build, and fix identified failures.
Maintainers of important packages should be prepared to assist.
Important (critical?) packages include:

- pkg
- binutils
- gcc
… (need to expand this list)

3. Post a Heads-Up email to at least the FreeBSD-current and
FreeBSD-ports mailing lists with a proposed schedule. Where
appropriate add other mailing lists, such as FreeBSD-toolchain. Allow
at least three weeks between the Heads-Up email and the commit.

4. In the period between the Heads-Up email and the commit, developers
proposing the change and maintainers of ports affected by the change
work together to resolve any ports failures.

5. Request additional exp-runs as necessary (by adding a comment in
the existing PR).

6. Commit may proceed once all important/critcal ports build, and either:

- The deadline proposed in the Heads-Up email has been reached
- There is a concensus that remaining failures are insignificant (for
example, a small number of unmaintained leaf ports are the only
outstanding failures)

7. Collaborate on fixing any outstanding issues (e.g. broken leaf ports)