From owner-freebsd-arch@freebsd.org Wed Oct 24 13:59:46 2018 Return-Path: Delivered-To: freebsd-arch@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 6041BFE92F9; Wed, 24 Oct 2018 13:59:46 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 C4656910C8; Wed, 24 Oct 2018 13:59:45 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w9ODxg2o028398; Wed, 24 Oct 2018 06:59:42 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w9ODxgF8028397; Wed, 24 Oct 2018 06:59:42 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201810241359.w9ODxgF8028397@pdx.rh.CN85.dnsmgr.net> Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers In-Reply-To: To: Warner Losh Date: Wed, 24 Oct 2018 06:59:42 -0700 (PDT) CC: freebsd-stable@freebsd.org, freebsd-net@freebsd.org, freebsd-arch@freebsd.org, freebsd-fcp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 13:59:46 -0000 ... deleted ... ... cc list trimmed, getting too many recepient gripes from mailman ... > > > > 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. > > > > > > > > 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. > > > > > > 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 > > ?not? in a particular place was clearly a clerical error. > > > > And I have read case law that boiled down to the presents vs absence > > of a comma in an agreement that had results far beyond "minor". > > > > Use of words minor and major should be red flags unless both > > or explicitly defined, and even then those definitions often > > have issues themselves. > > > > I'm not going to define every single word. FCP documents describe process. > They are not legal documents, nor should they be. Major and minor have > common enough meanings, and the basis of bylaws is that we trust core@. The trust isssue is not core (though in this specific case it is a core member submitting the FCP, that is not going to be the case always). The trust issue is do we allow the Author to make this minor/major change decission and how does core get informed that it has happened? -- Rod Grimes rgrimes@freebsd.org