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

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]

On Thu, May 29, 2014 at 01:35:45AM +0100, Ben Hutchings wrote:
> On Tue, 2014-05-27 at 20:10 -0400, Martin K. Petersen wrote:

> > 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.

> For consumer widgets, it appears that most vendors don't update the
> software, so they won't care that any out-of-tree drivers may break on
> the next kernel version.  In fact, they're likely to be starting with
> their SoC vendor's kernel tree which was forked a few years ago and has
> a ton of dirty performance hacks in the core.

This is very true, to a good approximation nobody in the consumer
electronics space cares in the slightest about upstream - it's just not
useful as-is.  These days it's likely to be the current Android kernel
at the time the SoC was current.  There is some pressure from some of
the more clueful system integrators to be working with upstream, partly
for bringing things forwards on new devices and partly for leveraging
the review.

> > 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.
> [...]

> I never had to go through legal review, though I certainly sanitised
> some commit messages based on my own knowledge of what product
> information was and wasn't already public.

Indeed, particularly around errata.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]