Re: [Ksummit-discuss] [TOPIC] Encouraging more reviewers

["Martin K. Petersen" <martin.petersen@oracle.com>]

>>>>> "Jiri" == Jiri Kosina <jkosina@suse.cz> writes:

Jiri> Are you implying that Linux is still not in a position to force HW
Jiri> vendor companies to rather invest 30 man-minutes in order to have
Jiri> a proper changelog and driver merged in Linus' tree compared to
Jiri> receiving bad public press when they are being rejected
Jiri> (especially for such negligible reason as changelog text)?

There are a few companies in the enterprise space that get it. But in
general it can be quite the challenge to get these vendors to see the
value of being good Linux citizens. And these companies are much less
susceptible to phoronix rants than entities producing consumer widgets.

These companies have internal development processes that are often quite
unfriendly to the way we work. More often than not, upstream drivers are
trailing internal driver trees by many, many months. Patches are only
sent upstream when there is a bit of slack in the engineering schedule.

In many cases upstream Linux is not seen as an important target because
the driver vendor will provide OEMs that ship their hardware with a
"value added" outbox driver tarball or CD. The server vendors are
partially to blame for keeping this dreadful anachronism alive. One
would think that "It Just Works with RHEL/SLES/OL" would be better story
than retrofitting tarball drivers and jeopardizing future kernel
updates. According to the server vendors, however, customers expect to
install an updated Linux driver just like they do on Windows. Otherwise
the perception is that Linux is lagging behind or poorly supported.
*sigh*

Vendor driver release cycles are often tied exclusively to new silicon
availability and internal firmware release schedules. Many vendors pay
little to no attention to Linux development cycles. Furthermore, driver
code is often shared between several operating systems so every patch
needs to undergo IP/legal review before it can be submitted upstream.
Internal commit messages often have partner references, bug numbers,
code names, etc. in them. So it's typically easier to just drop the
patch description than rewriting it and have the new text reviewed by
the legal team.

That's the sorry state of affairs. Part of the problem here is that many
of the enterprise drivers have been in the kernel for a very long time.
They predate things like staging and SubmittingPatches by many years.
And we have been poor at communicating that things have changed and
sometimes a bit too lenient at accepting patches.

We have had a several discussions about this problem the last 6 months,
including at LSF/MM. I have had meetings with several hw vendors this
spring trying to educate them about our "new" rules of engagement. It's
not easy, but I feel we're making progress. Worst case we'll send gregkh
wielding a clue bat...

-- 
Martin K. Petersen	Oracle Linux Engineering