freebsd stable - Oct 2018 - FCP-0101: Deprecating most 10/100 Ethernet drivers

> 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                                                 rgrimes at
freebsd.org

"Rodney W. Grimes" wrote:
> 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.
Yes !

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20181024/938a7121/attachment.sig>