Date: Fri, 31 Dec 2021 20:29:44 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Ed Maste <emaste@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, Kyle Evans <kevans@freebsd.org>, Stefan Esser <se@freebsd.org>, Antoine Brodin <antoine@freebsd.org>, src-committers <src-committers@freebsd.org>, "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>, dev-commits-src-main@freebsd.org, FreeBSD Ports Management Team <portmgr@freebsd.org> Subject: Re: git: e2650af157bc - main - Make CPU_SET macros compliant with other implementations Message-ID: <Yc9MGC/HG9/HxG/W@kib.kiev.ua> In-Reply-To: <CAPyFy2BYPwsS-8mTH%2BRHipqWebTJ8BGZ_HQh_HkpGvf6zO3FnA@mail.gmail.com> References: <202112301154.1BUBsR1q017491@gitrepo.freebsd.org> <CAALwa8m3u3xrO3N0j8um57qGTVnMEQwx1gP2YxJbzE5%2BLhbsWA@mail.gmail.com> <d1553b68-23dd-128e-6ac0-6c3c1f66c7cd@freebsd.org> <CACNAnaEbjRj9yGWtBMByVOET8FFjJQxQEiFuPbrya2CMePf8BQ@mail.gmail.com> <Yc8tgfSVhKZelwxg@kib.kiev.ua> <CACNAnaEWGMSM5beWZSfg_vsYwLL56PNzN-59Oq_7Bbvkzro10A@mail.gmail.com> <CANCZdfrnVESrXkf%2B%2BFqmrO55RQQMV-D8psPXL60WcEJL1HzaMQ@mail.gmail.com> <CAPyFy2BYPwsS-8mTH%2BRHipqWebTJ8BGZ_HQh_HkpGvf6zO3FnA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Yc9MGC/HG9/HxG/W>