From owner-freebsd-stable@freebsd.org Wed Oct 24 14:55:17 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E83B4FED73F; Wed, 24 Oct 2018 14:55:16 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86B0196672; Wed, 24 Oct 2018 14:55:16 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.27] ([194.32.164.27]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id w9OEtD1L009610; Wed, 24 Oct 2018 15:55:13 +0100 (BST) (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers From: rb@gid.co.uk In-Reply-To: Date: Wed, 24 Oct 2018 15:55:13 +0100 Cc: "Rodney W. Grimes" , Brooks Davis , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <994430B6-A8BC-4A1F-B15A-41E71DE5D47F@gid.co.uk> References: <20181023233716.GA15106@spindle.one-eyed-alien.net> <201810240002.w9O02tXg025019@pdx.rh.CN85.dnsmgr.net> <9257C84A-CA7C-42B9-9AD8-89AE33C96356@gid.co.uk> To: Warner Losh X-Mailer: Apple Mail (2.3273) X-Mailman-Approved-At: Wed, 24 Oct 2018 15:01:08 +0000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 14:55:17 -0000 > On 24 Oct 2018, at 14:39, Warner Losh wrote: >=20 > [stuff trimmed] >=20 >> >> The FCP process itself is unclear on this point, >> >> I think this should be clarified. >> >>=20 >> >> It is much more clear on post approval: >> >> Changes after acceptance >> >>=20 >> >> FCPs may need revision after they have been moved into the >> >> accepted state. In such cases, the author SHOULD update the >> >> FCP to reflect the final conclusions. >> >> If the changes are major, the FCP SHOULD be withdrawn >> >> and restarted. >> >>=20 >> >=20 >> > Good point Rod. While common sense suggests that trivial changes = during the >> > voting should be allowed for editorial purposes (eg fix grammar = mistakes, >> > table rendering etc), it's better to spell that out so there's no = confusion. >> >=20 >> > diff --git a/fcp-0000.md b/fcp-0000.md >> > index b4fe0f3..c8cc6f7 100644 >> > --- a/fcp-0000.md >> > +++ b/fcp-0000.md >> > @@ -144,7 +144,10 @@ When the discussion of a change has come to a = suitable >> > and acceptable close it >> > SHOULD be updated to the `vote` state. >> >=20 >> > At this time the FreeBSD Core Team will vote on the subject of the = FCP. The >> > -result of vote moves the FCP into the `accepted` or `rejected` = state. >> > +result of vote moves the FCP into the `accepted` or `rejected` = state. The >> > +core team MAY make minor edits to the FCP to correct minor = mistakes. Core >> > +MAY return the proposal to the submitter if there are major = problems that >> > +need to be addressed. >>=20 >> This is a Bad Idea, because it relies on common understanding of what = is minor. I was once involved with a standards body that had a procedure = for so-called clerical errors intended to deal with typos, punctuation = etc; this worked just fine until somebody claimed that the omission of = the word =E2=80=9Cnot=E2=80=9D in a particular place was clearly a = clerical error. >=20 > This documents procedure. It's not law. Trying to read it as law is a = mistake: it's written to be brief and descriptive, not through and = prescriptive. And that's on purpose. Axiom 1 of the bylaws is that you = can trust the core team, which is why the power grant is total and = unequivocal: Core is the governing body of the project. If you can't = trust the core team and need anything more, you've already list. And = over the years core's biggest failing isn't some fleet of black = helicopters dispatched to take out critics or other shenanigans. It's = either been not doing enough for the situation (due to too little time = and/or a mistaken impression that they couldn't do anything), or it's = lack of clear communication either between the different 'hats' and core = or between core and the rest of the project. >=20 > Warner=20 No problem with any of that. If the intent is that =E2=80=9Ccore MAY = make unrestricted changes to the FCP and/or MAY return the proposal to = the submitter if there are problems that need to be addressed=E2=80=9D = then say so. -- Bob Bishop t: +44 (0)118 940 1243 rb@gid.co.uk m: +44 (0)783 626 4518