svn commit: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

[Eric van Gyzen]

On 03/09/2018 10:00, Warner Losh wrote:
>
>
> On Fri, Mar 9, 2018 at 8:44 AM, Kyle Evans <kevans at freebsd.org
> <mailto:kevans at freebsd.org>> wrote:
>
>     On Fri, Mar 9, 2018 at 9:28 AM, Rodney W. Grimes
>     <freebsd at pdx.rh.cn85.dnsmgr.net
>     <mailto:freebsd at pdx.rh.cn85.dnsmgr.net>> wrote:
>     >> On Wed, Mar 07, 2018 at 02:53:49PM -0800, Eitan Adler wrote:
>     >> > On 7 March 2018 at 09:37, John Baldwin <jhb at freebsd.org
>     <mailto:jhb at freebsd.org>> wrote:
>     >> > > ...
>     >> > > I suspect many of these changes for iwm, etc. are all
>     intertwined
>     >> > > so I'm not sure if you can leave out individual ones.
>     >> >
>     >> > Possibly. I do have iwm working on my laptop though. I also
>     know of
>     >> > one open PR assigned to me w.r.t. a model I don't own. I'll be
>     >> > addressing it some time this week.
>     >>
>     >> I often have mixed feelings when I see lots of similar changes
>     (i.e.
>     >> that make up for better hardware support, esp. on a laptop) MFCed.
>     >> I'd rather see laptop users run -CURRENT and leave -STABLE branches
>     >> for very conservative (server?) users who can't/don't want to
>     afford
>     >> the risks of running -CURRENT or require ABI stability in a really
>     >> long run, rather than binge-merging things. :-)
>     >>
>     >> By default it should be -CURRENT all over; it's a very good thing
>     >> that we as a Project ourselves are doing this as part of our own
>     >> dogfood eating strategy.
>     >
>     > As a data point just last night a person came into #freebsd irc
>     > channel with a none working wireless nic on a desktop, he was
>     > attemtping to use a Realteak RTL8192EU on 11.1-RELEASE.
>     >
>     > Someone had already told him to try urtwn driver, which in
>     > -current is the right driver and supports this device.
>     >
>     > It did not work for him.  This is about when I came in to the
>     > discussion, and helped to confirm that -current did infact
>     > have support for this device, and that this supported had
>     > existed in -current for 16 months, and that this support
>     > would not be a simple grab a couple driver files and build
>     > it on 11.1.
>     >
>     > The commit to add this support involves 46 files, which 18
>     > of are new files.
>     >
>     > My feelings are if this driver has been in -current for
>     > 16 months why is it NOT in -stable yet?  I know part of
>     > the answer "its not a simple merge".  But as a project
>     > this is egg on our face.  We can merge a new very complicated
>     > change to a our boot code, within a few months (thank you
>     > kevans for that work), but we can not merge back a
>     > device driver in 16?
>     >
>
>     I had the same questions- this exact same person had hopped over to
>     #freebsd-wifi and I had walked through this same process, identifying
>     it as "not MFC-able" at this point because so many commits having been
>     left un-merged prior to it. I've already recently gone through the fun
>     of catching up on one and a half years worth of unmerged work in
>     stand, I'm not really prepared to do it again quite yet.
>
>     It felt pretty bad having to tell him that his only option here was to
>     either hop on -CURRENT + rtwn(4) or grab a stable/11 supported NIC-
>     especially since stable/11 is still supposed to be supported for
>     another three (3!) years, and I had to leave before I could help him
>     walk through getting it setup on -CURRENT properly
>
>
> one has to wonder why 12.0 is so far in the future....

My thoughts precisely.  If there is so much interesting content in head,
it's time for a release.

Eric