On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < freebsd-rwg at 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 at 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=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. 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
> On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > freebsd-rwg at pdx.rh.cn85.dnsmgr.net> 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 rgrimes at freebsd.org
> On 24 Oct 2018, at 01:23, Warner Losh <imp at bsdimp.com> wrote: > > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > freebsd-rwg at 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 at 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=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 > _______________________________________________ > freebsd-stable at freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" >-- Bob Bishop rb at gid.co.uk
> > On 24 Oct 2018, at 01:23, Warner Losh <imp at bsdimp.com> wrote: > > > > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > > freebsd-rwg at 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 at 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=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 > > _______________________________________________ > > freebsd-stable at freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" > > > > -- > Bob Bishop > rb at gid.co.uk-- Rod Grimes rgrimes at freebsd.org