From owner-freebsd-net@freebsd.org Wed Oct 24 13:39:33 2018 Return-Path: Delivered-To: freebsd-net@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 AA066FD95E7 for ; Wed, 24 Oct 2018 13:39:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D000F8E41A for ; Wed, 24 Oct 2018 13:39:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92a.google.com with SMTP id i30so1857280uae.11 for ; Wed, 24 Oct 2018 06:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ce+lKE4X4hw50P1h1G+iDhJtzQKtDvxqDUQWTCm/zKE=; b=U+gSsvik04vqMe9Cc/8IVBPsC9F3pOozU2dAod8wjwSmYH5J/EryEqaIo+wJDRWP6M UBVdeSQOhhm1cwjVJUbAYD5IGydWBDvb8tqy1uAQM9WpKSJ+0gv5r2BR3UX64UPqn+l5 b0us1D7JlZtuxBE4Cie7oLXD+h1OxnaXVauuk8Aq1pzeKRO1bJvCXsLUMBR+r97SLR+a x39fwWRc1iI5YcHO+EYr2tbgjcKA16H0nQANlAUIJDOPu5bOqutUlIvcip8OQ/JHWXde bxXFGYkHV9pkQvuO1yLsBPWlh1f4QXfB363eApiGjLs6QPgCOLVyqwD7GzVwc7TKQ8QP 9csA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ce+lKE4X4hw50P1h1G+iDhJtzQKtDvxqDUQWTCm/zKE=; b=i15XStytPpg1BeEgNi7bVhlmM0QuzbdqD9kPb5SmK3ANx/MFNj/y4dXLYnRlN7SMI0 KHzxxJjJyYSQcdNjFXR3wBfZRaxDVYvjSjA36UE9NykWwx+o9yvwRgSIUBHfofyqQDXF yA2PDLlW1/WYUjpUmINYpqKfeW2EKTlsiXZdyvXFSt/UXajNYRkP6uD4pJYJTHbS/dRK H3v+xoHNbgnZcuH8FKJ2fqdwx7hAggj8bfEQib7FFSEXsDHhQw5uJkAAap/kFEXAE9zU HoTm3KKH+2UdH3PUymahdRZZpwKF/GltTQ59Al8W1lHa0KBF6FJZSISp4K8wv+DG2Co1 fbOg== X-Gm-Message-State: AGRZ1gIDyuHBbtIi+SErg5I+R8A4j0u+iW+sQn6b8riZF9fWBYjliuIT l2EAyqp/aEJ3ctnpDD+/vLhfo3z0BUW7uYVr6sUtsQ== X-Google-Smtp-Source: AJdET5dirytD25FAxg9qrHowfcJcAQMkWc1rCZbTcOiTB+772fCVD9SZwrRxVtIsVSuu2+xgSV9/oiAxNMSf6H3WmVI= X-Received: by 2002:ab0:53c3:: with SMTP id l3mr1139500uaa.16.1540388371742; Wed, 24 Oct 2018 06:39:31 -0700 (PDT) MIME-Version: 1.0 References: <20181023233716.GA15106@spindle.one-eyed-alien.net> <201810240002.w9O02tXg025019@pdx.rh.CN85.dnsmgr.net> <9257C84A-CA7C-42B9-9AD8-89AE33C96356@gid.co.uk> In-Reply-To: <9257C84A-CA7C-42B9-9AD8-89AE33C96356@gid.co.uk> From: Warner Losh Date: Wed, 24 Oct 2018 07:39:20 -0600 Message-ID: Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers To: Bob Bishop 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 X-Mailman-Approved-At: Wed, 24 Oct 2018 14:10:42 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 13:39:34 -0000 On Wed, Oct 24, 2018 at 5:02 AM Bob Bishop wrote: > > > On 24 Oct 2018, at 01:23, Warner Losh wrote: > > > > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > >> -- Start of PGP signed section. > >>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: > >>>>> On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > >>>>> freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > >>>>> > >>>>>>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > >>>>>>>>> I'd also suggest that rl stands in stark contrast to the cs, > >> wb, sn, > >>>>>> smc, > >>>>>>>>> sf, tl, tx and vr drivers, which nobody has mentioned in this > >>>>>> thread, and > >>>>>>>>> which I doubt are in use in any FreeBSD system of any age > >> today. > >>>>>>>> > >>>>>>>> vr is used by my TV driver laptop: > >>>>>>>> http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > >>>>>>>> vr0: flags=3D8843 metric > >> 0 mtu > >>>>>> 1500 > >>>>>>>> options=3D82808 > >>>>>>>> ether 00:40:d0:5e:26:38 > >>>>>>>> inet 192.168.91.65 netmask 0xffffff00 broadcast > >> 192.168.91.255 > >>>>>>>> media: Ethernet autoselect (100baseTX > >>>>>> ) > >>>>>>>> status: active > >>>>>>>> > >>>>>>>> Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade > >> soon > >>>>>>>> when I also configure it to receive from a raspberry-pi TV VPN > >> server. > >>>>>>> > >>>>>>> The above was a typo. vr is on the the STAY list. > >>>>>>> > >>>>>>> -- Brooks > >>>>>> Brooks, > >>>>>> Is there a public revised version of FCP-0101 that > >> reflects the > >>>>>> feedback which is what core is voting on? > >>>>>> > >>>>> > >>>>> Its on github, just like it's been the whole time for anybody to se= e, > >>>>> submit pull requests against and track: > >>>> > >>>> I have no gh account, desires no gh account, so have no way to > >>>> submit a change request other than through direct email to > >>>> brooks or another gh user. This is fundementally flawed. > >>>> > >>>>> https://github.com/freebsd/fcp/blob/master/fcp-0101.md > >>>> > >>>> Thank you for the link, I had looked at it before MeetBSD, > >>>> which did not have most of the recent changes done "a day ago". > >>>> > >>>> Isnt this document now in a frozen state while core reviews/votes? > >>> > >>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only > >>> to notice a bug in table rendering. I submitted a pull request fix > >>> that and a missing word which was merged since neither was material. = I > >>> suppose they could have waited or been skipped, but there's no value = in > >>> the FCP process being bound by the sort of pointless rigidity that le= d > >>> to -DPOSIX_MISTAKE in every libc compile line. > >> > >> The FCP process itself is unclear on this point, > >> I think this should be clarified. > >> > >> It is much more clear on post approval: > >> Changes after acceptance > >> > >> 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. > >> > > > > Good point Rod. While common sense suggests that trivial changes during > the > > voting should be allowed for editorial purposes (eg fix grammar mistake= s, > > table rendering etc), it's better to spell that out so there's no > confusion. > > > > 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 wor= d > =E2=80=9Cnot=E2=80=9D in a particular place was clearly a clerical error. > 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. Warner