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

On Fri, Dec 31, 2021 at 01:08:25PM -0500, Ed Maste wrote:
> 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.
And what to do if developers are not 'collaborative'?  For my case, there
was a silence from ports maintainers, even after
- a tool was proposed
- a request for feedback was issued

> 
> 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)

This is good wishes, at best. This assessment is backed by my experience
both with ino64, and with sched_get/setaffinity. Either source changes
are blocked indefinitely, or source committer is tasked with fixing all
broken ports.