FCP-0101: Deprecating most 10/100 Ethernet drivers

[rb at gid.co.uk]

> On 24 Oct 2018, at 14:39, Warner Losh <imp at bsdimp.com> wrote:
> 
> [stuff trimmed]
> 
>> >> 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 mistakes,
>> > 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 word “not” 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 

No problem with any of that. If the intent is that “core 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” then say so.

--
Bob Bishop       t: +44 (0)118 940 1243
rb at gid.co.uk     m: +44 (0)783 626 4518