From nobody Fri Dec 31 18:34:34 2021 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 89F721927DA9 for ; Fri, 31 Dec 2021 18:34:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQYhk2lCJz3mWh for ; Fri, 31 Dec 2021 18:34:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2c.google.com with SMTP id h5so7366349vkp.5 for ; Fri, 31 Dec 2021 10:34:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4k4H6qU5sLipAovdHpzsTxglmapZ6beHuTAo+zMvvuM=; b=qSqUy5pjnuuE/k8BbVfIjoVYR+WIbv5CRm4pdaLwqZqnoR9ZIl2S3ZnZ68nb489vtY pTsofw+NO2pk1vdXKK73qR81y+wQTyC2WqdMw345IB1Q7DTwtej6CZg4yu9UwxWOT/1q CdAhkG8DLrqJ8CABMtEeVsa3fcrlJg1YKJ02w+h3OmKCfkzbxVUvnfQuxTl773dH2hlW wKtxYLr4jJUZ3YbqfTDP7WISVHh3WGJljoQ1YbMsatZyNSZrl9XJHG1u2CdOUz12o+Rr 6P1RxgakwcZ070oUQx+68Yj1FCrsyG4zM8LPN7ZrI1B6l1ISYbQYjqhAEnBmbULwGs9O GjlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4k4H6qU5sLipAovdHpzsTxglmapZ6beHuTAo+zMvvuM=; b=DaRnADqon63CB5gom96R0Bp3Hsx4/0kiWQzcfIPL/3QeC1vt1Y3rw1bgIPR9d3uoSQ N+YED/KT7aNahyA/qcSlXGhs9XGzzlvdtdqN234dTYQYPWCHiyF4JyArLzqsaZlyBB96 s83lTvvDzhDtDhHK0xO8UKYwbmd1UuL+vUIWEhQce0RYKwQyot7Sl/bAROuFCom9RWY9 LRwo/4/jWKJy0pC0uIRUjihjFogm2OwcwdYUpefVPDgb5Jk9KcWHMpFFqMgWHkTa9PZf I2yuCNiaVi59/WH3++O6aGnPkYPCz8eT3cNvb4spCLIyf/RVfE4t0XYMIg4ioeqKmDiw Jprg== X-Gm-Message-State: AOAM533iVE0viBik5vm9Vr0bkxPbw6gwqt+LUQirJ/g9DM1doCdd6utv e7y5hYe1bi+lrcVFjTRCOZPPl3E9CRxx460L10Ua6w== X-Google-Smtp-Source: ABdhPJy/zzwMjNUWeLe0JQ+eVIkhE+nOcN+GrZ3rUsbKPV9mweOKdWt4E2AOw7POGhCJdEMvFFWa/b9/GiD2p7WmGG8= X-Received: by 2002:a05:6122:da0:: with SMTP id bc32mr666487vkb.26.1640975685500; Fri, 31 Dec 2021 10:34:45 -0800 (PST) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 References: <202112301154.1BUBsR1q017491@gitrepo.freebsd.org> In-Reply-To: From: Warner Losh Date: Fri, 31 Dec 2021 11:34:34 -0700 Message-ID: Subject: Re: git: e2650af157bc - main - Make CPU_SET macros compliant with other implementations To: Konstantin Belousov Cc: Ed Maste , Kyle Evans , Stefan Esser , Antoine Brodin , src-committers , "" , dev-commits-src-main@freebsd.org, FreeBSD Ports Management Team Content-Type: multipart/alternative; boundary="000000000000d1fcbf05d4756cca" X-Rspamd-Queue-Id: 4JQYhk2lCJz3mWh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000d1fcbf05d4756cca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 31, 2021 at 11:29 AM Konstantin Belousov wrote: > 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 > > =E2=80=A6 (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 > There's a timeout in ports. If the maintainer is unresponsive, you can proceed. There's some tweaking we can do to the timeouts, to be sure, but I've had several things time out and I was good to proceed with my changes. For base changes in ABI, maybe we need a faster expectation for feedback as well as allowing breakage when the timeout is reached and there aren't some compelling reasons not to proceed. > > > > 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 eithe= r: > > > > - 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. > It's never that absolute: I've made changes I knew would break ports that were deemed to be unsupported enough to just mark broken. But having a list of things that might be broken allowed me to work with portmgr to make this call. Warner --000000000000d1fcbf05d4756cca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 31, 2021 at 11:29 AM Kons= tantin Belousov <kostikbel@gmail.= com> wrote:
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 discuss= ion.
> ---
> 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.<= br> > Maintainers of important packages should be prepared to assist.
> Important (critical?) packages include:
>
> - pkg
> - binutils
> - gcc
> =E2=80=A6 (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<= br> > 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'?=C2=A0 For my = case, there
was a silence from ports maintainers, even after
- a tool was proposed
- a request for feedback was issued

The= re's a timeout in ports. If the maintainer is unresponsive, you can pro= ceed.
There's some tweaking we can do to the timeouts, to be = sure, but I've had several
things time out and I was good to = proceed with my changes.

For base changes in ABI, = maybe we need a faster expectation for feedback as
well as allowi= ng breakage when the timeout is reached and there aren't some
compelling reasons not to proceed.
=C2=A0
>
> 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 eith= er:
>
> - The deadline proposed in the Heads-Up email has been reached
> - There is a concensus that remaining failures are insignificant (for<= br> > example, a small number of unmaintained leaf ports are the only
> outstanding failures)
>
> 7. Collaborate on fixing any outstanding issues (e.g. broken leaf port= s)

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.

It's never that absol= ute: I've made changes I knew would break ports that
were dee= med to be unsupported enough to just mark broken. But having a list
of things that might be broken allowed me to work with portmgr to make t= his call.

Warner
--000000000000d1fcbf05d4756cca--