Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

classic Classic list List threaded Threaded
101 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Warner Losh
On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes <
[hidden email]> 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=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> 1500
> > >         options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
> > >         ether 00:40:d0:5e:26:38
> > >         inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255
> > >         media: Ethernet autoselect (100baseTX
> <full-duplex,flowcontrol,rxpause,txpause>)
> > >         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 see,
submit pull requests against and track:

https://github.com/freebsd/fcp/blob/master/fcp-0101.md

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Rodney W. Grimes-4
> On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes <
> [hidden email]> 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=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> > 1500
> > > >         options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
> > > >         ether 00:40:d0:5e:26:38
> > > >         inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255
> > > >         media: Ethernet autoselect (100baseTX
> > <full-duplex,flowcontrol,rxpause,txpause>)
> > > >         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 see,
> 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?


--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Brooks Davis-2
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 <
> > [hidden email]> 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=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> > > 1500
> > > > >         options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
> > > > >         ether 00:40:d0:5e:26:38
> > > > >         inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255
> > > > >         media: Ethernet autoselect (100baseTX
> > > <full-duplex,flowcontrol,rxpause,txpause>)
> > > > >         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 see,
> > 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 led
to -DPOSIX_MISTAKE in every libc compile line.

-- Brooks

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Rodney W. Grimes-4
-- 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 <
> > > [hidden email]> 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=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> > > > 1500
> > > > > >         options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
> > > > > >         ether 00:40:d0:5e:26:38
> > > > > >         inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255
> > > > > >         media: Ethernet autoselect (100baseTX
> > > > <full-duplex,flowcontrol,rxpause,txpause>)
> > > > > >         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 see,
> > > 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 led
> 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.

--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Warner Losh
In reply to this post by Rodney W. Grimes-4
On Tue, Oct 23, 2018 at 5:26 PM Rodney W. Grimes <
[hidden email]> wrote:

> > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes <
> > [hidden email]> 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=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
> mtu
> > > 1500
> > > > >         options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
> > > > >         ether 00:40:d0:5e:26:38
> > > > >         inet 192.168.91.65 netmask 0xffffff00 broadcast
> 192.168.91.255
> > > > >         media: Ethernet autoselect (100baseTX
> > > <full-duplex,flowcontrol,rxpause,txpause>)
> > > > >         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 see,
> > 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.
>

The fcp process was officially approved by core.9. You can make suggestions
to core for improvements to the process. Lord knows this FCP hasn't been
trouble free (though we've learned some valuable lessons). Submissions to
the author is always an option should you choose not to use the widely used
technology we've chosen to automate this process. Some FreeBSD users don't
have accounts, however, many non-developers have github accounts and I
think it's a reasonable way to do outreach to the larger community w/o
requiring everybody to get a freebsd account (since they are already likely
to have a github account, and if not they are trivial to get).

So yea, it's a flawed process, and we'd love feedback on actionable items
we can do to make it better.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Rodney W. Grimes-4
In reply to this post by Robert Clausecker
> On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes <
> [hidden email]> wrote:
... deleted un relavent text ...

> > > > > > 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 see,
> > > > > 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 led
> > > 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 mistakes,
> table rendering etc), it's better to spell that out so there's no confusion.

Agreed.

>
> 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 allows and clarifies that core may modify it,
it does not address if the author/submitter can modify it.

>
>  FCPs in the `accepted` state can be updated and corrected.
>  See the "Changes after acceptance" section for more information.
>
> Normally I'd submit that as a pull request, but since I know you don't use
> github, I thought I'd present it here to see if this answers your concerns
> before doing so.

I thank you very much for that consideration,
--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Joel Dahl-3
In reply to this post by Robert Clausecker
On Wed, Oct 03, 2018 at 09:05:16PM +0000, Brooks Davis wrote:

> >>> Please direct replies to freebsd-arch <<<
>
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack.  We have discussed this within the
> core team and intend to move forward as proposed.  We are solictiting
> feedback on the list of drivers to be excepted from removal.
>
> The current list of drivers slated for REMOVAL is:
>
> ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
> ste, tl, tx, txp, vx, wb, xe

The list above does not mention de(4). It is however on the FCP github page,
in the list of drivers planned for removal. Which list is correct?

--
Joel
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Bob Bishop
In reply to this post by Rodney W. Grimes-4

> On 24 Oct 2018, at 01:23, Warner Losh <[hidden email]> wrote:
>
> On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes <
> [hidden email]> 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 <
>>>>> [hidden email]> 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=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric
>> 0 mtu
>>>>>> 1500
>>>>>>>>        options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
>>>>>>>>        ether 00:40:d0:5e:26:38
>>>>>>>>        inet 192.168.91.65 netmask 0xffffff00 broadcast
>> 192.168.91.255
>>>>>>>>        media: Ethernet autoselect (100baseTX
>>>>>> <full-duplex,flowcontrol,rxpause,txpause>)
>>>>>>>>        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 see,
>>>>> 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 led
>>> 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 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.

> FCPs in the `accepted` state can be updated and corrected.
> See the "Changes after acceptance" section for more information.
>
> Normally I'd submit that as a pull request, but since I know you don't use
> github, I thought I'd present it here to see if this answers your concerns
> before doing so.
>
> Warner
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[hidden email]"
>

--
Bob Bishop
[hidden email]




_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Rodney W. Grimes-4
> > On 24 Oct 2018, at 01:23, Warner Losh <[hidden email]> wrote:
> >
> > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes <
> > [hidden email]> 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 <
> >>>>> [hidden email]> 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=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric
> >> 0 mtu
> >>>>>> 1500
> >>>>>>>>        options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
> >>>>>>>>        ether 00:40:d0:5e:26:38
> >>>>>>>>        inet 192.168.91.65 netmask 0xffffff00 broadcast
> >> 192.168.91.255
> >>>>>>>>        media: Ethernet autoselect (100baseTX
> >>>>>> <full-duplex,flowcontrol,rxpause,txpause>)
> >>>>>>>>        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 see,
> >>>>> 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 led
> >>> 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 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.

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.

> > FCPs in the `accepted` state can be updated and corrected.
> > See the "Changes after acceptance" section for more information.
> >
> > Normally I'd submit that as a pull request, but since I know you don't use
> > github, I thought I'd present it here to see if this answers your concerns
> > before doing so.
> >
> > Warner
> > _______________________________________________
> > [hidden email] mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "[hidden email]"
> >
>
> --
> Bob Bishop
> [hidden email]

--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Warner Losh
In reply to this post by Bob Bishop
On Wed, Oct 24, 2018 at 5:02 AM Bob Bishop <[hidden email]> wrote:

>
> > On 24 Oct 2018, at 01:23, Warner Losh <[hidden email]> wrote:
> >
> > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes <
> > [hidden email]> 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 <
> >>>>> [hidden email]> 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=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric
> >> 0 mtu
> >>>>>> 1500
> >>>>>>>>        options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
> >>>>>>>>        ether 00:40:d0:5e:26:38
> >>>>>>>>        inet 192.168.91.65 netmask 0xffffff00 broadcast
> >> 192.168.91.255
> >>>>>>>>        media: Ethernet autoselect (100baseTX
> >>>>>> <full-duplex,flowcontrol,rxpause,txpause>)
> >>>>>>>>        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 see,
> >>>>> 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 led
> >>> 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 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Mark Linimon-2
In reply to this post by Rodney W. Grimes-4
On Wed, Oct 24, 2018 at 05:19:33AM -0700, Rodney W. Grimes wrote:
> And I have read case law that boiled down to the presents vs absence
> of a comma

If we are now going to evaluate all proposed changes to FreeBSD on the
same rigid principles as the US legal system, I'm done.

mcl
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Warner Losh
In reply to this post by Rodney W. Grimes-4
On Wed, Oct 24, 2018 at 6:19 AM Rodney W. Grimes <
[hidden email]> wrote:

> > > On 24 Oct 2018, at 01:23, Warner Losh <[hidden email]> wrote:
> > >
> > > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes <
> > > [hidden email]> 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 <
> > >>>>> [hidden email]> 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=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric
> > >> 0 mtu
> > >>>>>> 1500
> > >>>>>>>>        options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
> > >>>>>>>>        ether 00:40:d0:5e:26:38
> > >>>>>>>>        inet 192.168.91.65 netmask 0xffffff00 broadcast
> > >> 192.168.91.255
> > >>>>>>>>        media: Ethernet autoselect (100baseTX
> > >>>>>> <full-duplex,flowcontrol,rxpause,txpause>)
> > >>>>>>>>        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
> see,
> > >>>>> 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
> led
> > >>> 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
> 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.
>
> 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@.

Warner


> > > FCPs in the `accepted` state can be updated and corrected.
> > > See the "Changes after acceptance" section for more information.
> > >
> > > Normally I'd submit that as a pull request, but since I know you don't
> use
> > > github, I thought I'd present it here to see if this answers your
> concerns
> > > before doing so.
> > >
> > > Warner
> > > _______________________________________________
> > > [hidden email] mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > To unsubscribe, send any mail to "
> [hidden email]"
> > >
> >
> > --
> > Bob Bishop
> > [hidden email]
>
> --
> Rod Grimes
> [hidden email]
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Rodney W. Grimes-4
In reply to this post by Mark Linimon-2
> On Wed, Oct 24, 2018 at 05:19:33AM -0700, Rodney W. Grimes wrote:
> > And I have read case law that boiled down to the presents vs absence
> > of a comma
>
> If we are now going to evaluate all proposed changes to FreeBSD on the
> same rigid principles as the US legal system, I'm done.

I do not think "all" is in scope here,
but I do feel should excercise care about procedure.
And FYI, the case law above I am pretty sure was not US.

I also believe that what is at issue here can be fixed
rather easily without ever going down the minor vs major
slippery slope by some rather simple changes to order
of events and careful steps.

Warner came very close, I think he just applied his correct
"fix" to 1/2 of the problem.

There is the stage where the FCP is before core being voted
on, and there is the stage that the FCP has been approved.
He only addressed 1 of those, and he did so by allowing core
to trivially modify the document during the voting process,
and I am actually fine with that idea, its good, it is what
should be allowed.  I trust core to know what is minor vs
major.

BUTT it still does not cover the issue of the author/submitter
modifying the document while it is in core being reviewed and
possibly modified.  I have issue with that.  It is very hard
to vote/formally review on something that is fluid.
I have not been asked to trust these people with the trust I
give core, so I would like to remove that.

We could add that once the document is submitted to core
any change to it between submitting and vote by core requires
core to be involved, even if it is simply an ack of a change
has been made to what was submitted.

--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Rodney W. Grimes-4
In reply to this post by Warner Losh
... 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                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Julian H. Stacey-3
In reply to this post by Warner Losh
I suggest posters to this lively thread could strip inherited personal
CC addresses .  Then ~/.procmailrc that sorts list mail away from
real personal ~/mail/Inbox will protect xbiff from beeping so much :-)

Cheers,
Julian
--
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich.
 Brexit referendum stole 3,700,000 Brits votes abroad, inc. 700,000 in EU.
 Campaign lies, criminal funding, economy & pound down. Time for an honest ref.
        http://exitbrexit.uk        https://www.peoples-vote.uk/petition
                https://eci.ec.europa.eu/002/public/#/initiative
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Bob Bishop
In reply to this post by Warner Losh

> On 24 Oct 2018, at 14:39, Warner Losh <[hidden email]> 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
[hidden email]     m: +44 (0)783 626 4518





_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Brooks Davis-2
In reply to this post by Rodney W. Grimes-4
On Wed, Oct 24, 2018 at 06:54:01AM -0700, Rodney W. Grimes wrote:

> > On Wed, Oct 24, 2018 at 05:19:33AM -0700, Rodney W. Grimes wrote:
> > > And I have read case law that boiled down to the presents vs absence
> > > of a comma
> >
> > If we are now going to evaluate all proposed changes to FreeBSD on the
> > same rigid principles as the US legal system, I'm done.
>
> I do not think "all" is in scope here,
> but I do feel should excercise care about procedure.
> And FYI, the case law above I am pretty sure was not US.
>
> I also believe that what is at issue here can be fixed
> rather easily without ever going down the minor vs major
> slippery slope by some rather simple changes to order
> of events and careful steps.
>
> Warner came very close, I think he just applied his correct
> "fix" to 1/2 of the problem.
>
> There is the stage where the FCP is before core being voted
> on, and there is the stage that the FCP has been approved.
> He only addressed 1 of those, and he did so by allowing core
> to trivially modify the document during the voting process,
> and I am actually fine with that idea, its good, it is what
> should be allowed.  I trust core to know what is minor vs
> major.
>
> BUTT it still does not cover the issue of the author/submitter
> modifying the document while it is in core being reviewed and
> possibly modified.  I have issue with that.  It is very hard
> to vote/formally review on something that is fluid.
> I have not been asked to trust these people with the trust I
> give core, so I would like to remove that.
There are technical measures in place that do much of this already.
Right now, authors can't directly change the documents (unless they are
repo admins which means core and former core members in practice).  We
require that pull requests be reviewed before they are merged and random
people don't have commit access.  We could make the restriction to core
members or core members and fcp-editors explicit if that was desirable.

> We could add that once the document is submitted to core
> any change to it between submitting and vote by core requires
> core to be involved, even if it is simply an ack of a change
> has been made to what was submitted.

I agree.  We'll need to think on how best to do this.

-- Brooks

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Brooks Davis-2
In reply to this post by Joel Dahl-3
On Wed, Oct 24, 2018 at 08:13:19AM +0200, Joel Dahl wrote:

> On Wed, Oct 03, 2018 at 09:05:16PM +0000, Brooks Davis wrote:
> > >>> Please direct replies to freebsd-arch <<<
> >
> > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> > and remove them in FreeBSD 13 to reduce the burden of maintaining and
> > improving the network stack.  We have discussed this within the
> > core team and intend to move forward as proposed.  We are solictiting
> > feedback on the list of drivers to be excepted from removal.
> >
> > The current list of drivers slated for REMOVAL is:
> >
> > ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
> > ste, tl, tx, txp, vx, wb, xe
>
> The list above does not mention de(4). It is however on the FCP github page,
> in the list of drivers planned for removal. Which list is correct?
The FCP page is the source of truth in all cases.  It was missed in the
initial survey and added later.

-- Brooks

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Alexey Dokuchaev-4
In reply to this post by Ian Lepore-3
On Thu, Oct 04, 2018 at 11:38:46AM -0600, Warner Losh 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.

Warner, I had mentioned [*] that I'm using sf(4), would you please be more
careful when collecting "NICs still in use" data?  We really do need a wiki
page and carefully relect all the feedback we've received so far and also
upcoming one.

./danfe

[*] Message-ID: <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

John-Mark Gurney-2
In reply to this post by Rodney W. Grimes-4
Rodney W. Grimes wrote this message on Wed, Oct 24, 2018 at 05:19 -0700:
> 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".

For those currious about this case:
https://www.bostonglobe.com/business/2017/03/16/lack-oxford-comma-costs-maine-company-millions-overtime-dispute/BIxK837fA2C06qavQMDs5J/story.html

--
  John-Mark Gurney Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
123456