svn commit: r344027 - in stable/12/sys: dev/vmware/vmxnet3 modules/vmware/vmxnet3 net

[Patrick Kelsey]

On Tue, Feb 12, 2019 at 4:31 AM Rodney W. Grimes <
freebsd at pdx.rh.cn85.dnsmgr.net> wrote:

> > On Mon, Feb 11, 2019 at 8:13 PM Patrick Kelsey <pkelsey at freebsd.org>
> wrote:
> >
> > >
> > >
> > > On Mon, Feb 11, 2019 at 8:08 PM John Baldwin <jhb at freebsd.org> wrote:
> > >
> > >> On 2/11/19 4:26 PM, Rodney W. Grimes wrote:
> > >> >> Author: pkelsey
> > >> >> Date: Mon Feb 11 23:24:39 2019
> > >> >> New Revision: 344027
> > >> >> URL: https://svnweb.freebsd.org/changeset/base/344027
> > >> >>
> > >> >> Log:
> > >> >>   MFC r343291:
> > >> >>   Convert vmx(4) to being an iflib driver.
> > >> >
> > >> > I strongly object to this MFC, given the current number
> > >> > of 12.0 RELEASE related iflib problems we have it is
> > >> > foolish of us to iflib any more drivers in 12.0
> > >>
> > >> This isn't the release branch though and presumably we have some time
> > >> before
> > >> 12.1 ships.  If there are reports of vmx(4) breakage on stable before
> 12.1
> > >> we could always revert this commit then?
> > >>
> > >> I've heard of some EN's for 12.0 for iflib fixes.  Are those fixes in
> > >> stable/12
> > >> yet or are we still waiting for them to land in HEAD and/or be merged?
> > >>
> > >
> > > iflib.c is currently the same between head and stable/12.  I've found
> and
> > > fixed a number of iflib bugs by developing the iflib version of the
> vmx(4)
> > > driver, and it's also being fielded in a product.  I'm also aware that
> not
> > > all current driver problems are necessarily iflib problems.  I think
> we'd
> > > be better off letting this version of vmx(4) ride it out in stable/12
> until
> > > such time as we discover an actual horror that we then feel we need to
> > > react to in some way other than just going ahead and fixing it.
> > >
> > >
> > John,
> >
> > Which is to say, I second your motion to proceed with normal process.  As
>
> Point of order here, per the commiters guide you do not have the option
> of seconding any motion that should of never been made, per rule 6 a
> request by a Maintainer to revert your change has been made.  There
> is no arguing on that point.
>
>
I think you may have caused a bit of confusion when you opened with "please
consider reverting this until the iflib issues are resolved", as then jhb@
and I both seem to have gone and considered it not recognizing that you
were actually making a demand.

-Patrick