[Ksummit-discuss] [Stable kernel] feature backporting collaboration

[Mark Brown]

On Wed, Sep 21, 2016 at 05:28:19PM +0200, gregkh at linuxfoundation.org wrote:
> On Wed, Sep 21, 2016 at 10:52:19PM +0800, Alex Shi wrote:

> > I have left Intel Open source center for 3 years, may I miss some
> > changes in Intel. In my memory, Intel has no soft product on its leading
> > open source project, like virtualization or others. On android or
> > previous meego project, it's still use 'old' kernel with much of
> > down-stream patches.

> Being one of the previous Meego kernel maintainers, and in charge of a
> number of laptops that shipped Meego images (we made money on
> preinstalled Linux!) I strongly disagree with that statement.  We spent
> a lot of time getting all of the work we did for Meego upstream when we
> added it to our kernels, there was no deviation there at all.

Sadly the x86 Android phones I've seen were no different to any other
Android phone in this regard.

> We know bug reports come from everyone, there is no such thing as "bug
> free software", and none of us are claiming it.  What we are claiming is
> that you should stick to the tree that is tested by as many people as
> possible the closest (i.e. mainline) as that gets you the most bug
> fixes, as well as the ability to use the kernel community to help you
> out when you have problems.  Otherwise you are on your own with your
> 2.5million lines added franken-kernel that no one will touch if they
> have a choice not to.

That diff isn't going to go away overnight of course...

> > There are do many guys 'ignore' the upstream work with a huge 'time to
> > market' pressure. But there are not only their fault, community may need
> > some better ways to help them out.

> Ok, why are they not talking to us?  We are easy to find, just look at
> our inboxes :)

> What do you think we could do to help them out?  That's what I have been
> doing for the past 10 years in going around and working with companies.
> But it's a two-way street, we aren't going to suddenly stop development
> on new kernels and just focus on one specific one for a full year, you
> have to be realistic.

Right, as do we.  People's code isn't magically going to get upstreamed
overnight, it takes time especially if the hardware isn't designed in a
way that Linux expects and needs some substantial framework adjustments
(which is a serious problem for some of the SoCs).

> > BTW, I take back this word. There are may some industry out of my
> > experience which is doing so. But let me know the case.

> Lots of them are, look at the customers of Renesas as one such example
> of an SoC company that knows how to do this well, and is doing a great
> job.  And their customers seem to appreciate it from what I can tell.

They are one of the better engaged vendors, as are companies like Atmel,
TI and nVidia (pulling names off the top of my head here), but talking
to their downstreams they do still have product kernels with a bunch of
things in them which have not all seen the light of upstream.  It's not
black or white, it's shades of grey.

You're asking what we can do to help - one of the biggest things I wish
we did more of was spend time calling out good practice rather than
complaining about bad practice.  Help people see changes they can make
today rather than talking only about a far off, distant goal.  Encourage
people doing these things to talk about the day to day benefits they've
seen.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20160921/949978d8/attachment.sig>