All of lore.kernel.org
 help / color / mirror / Atom feed
From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: Alex Shi <alex.shi@linaro.org>
Cc: "ltsi-dev@lists.linuxfoundation.org"
	<ltsi-dev@lists.linuxfoundation.org>,
	ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [Stable kernel] feature backporting collaboration
Date: Wed, 21 Sep 2016 17:28:19 +0200	[thread overview]
Message-ID: <20160921152819.GA25212@kroah.com> (raw)
In-Reply-To: <57E29EA3.2000605@linaro.org>

On Wed, Sep 21, 2016 at 10:52:19PM +0800, Alex Shi wrote:
> 
> 
> On 09/21/2016 05:23 PM, gregkh@linuxfoundation.org wrote:
> >> > 
> >> > I am not a fun of some scheduler solution. But focus on this can not
> >> > explain why many distributions are using 'old' stable kernel. Looking
> >> > into product world, could you find some real product are using
> >> > 'upstream' kernel?
> >> > 
> >> > 'upstream first' is good for feature development, but isn't good for
> >> > product.
> > Not true, IBM and Intel have shown that it saves you time and money to
> > do "upstream first", why do people claim that their reports of this is
> > somehow false?  Other companies also agree, but just don't want to take
> > the initial "hit" of time to do it correctly as it will affect the
> > device today to save time and money for the device tomorrow.
> 
> Thanks for quick response!
> 
> 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.

> So would you like to tell me more detailed info of IBM, Intel case?

It's online somewhere, and has been described in many presentations from
executives of both companies.  I think there was a business "whitepaper"
written somewhere as well that went into the details.

> >> > Many product guys talked to me that the non-upstream porting didn't
> >> > cost much and not the reason to pin on some stable kernel.
> > You must be talking to product people who only have to make one device,
> > not a family of devices :)
> 
> No, what I asked is one of Linaro core member, they are also leading
> company in mobile phone.

Lots of companies ship mobile phones, none of them do it well :)

> >> > All of them said that testing and stability was the most cost part.
> > Sure, software is always free, it's that pesky testing and fixing all of
> > the bugs found that costs money :)
> > (hint, all of those backports and non-upstrem stuff is what is causing
> > lots of those bugs...)
> > 
> >> > Not only the regular test case, benchmarks, but also the long time
> >> > using for some trick/corner case bugs in whole system.
> > What do you mean by this?
> 
> Uh, they are not so confident on the whole system stability, bug maybe
> come from middle layer, or user APP the compatibility with kernel.

Really?  That's news to me, what are we breaking at that layer?  We
ALWAYS want to know information like that as we do not accept that.

> Regular testing cannot cover everything, some bug report also come from
> consumers.

Sure, you do realize you are talking to lots of people here who
individually have decades of shipping Linux products on lots of
different platforms?  :)

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.

> >> > I doubt the 'keep rebasing on upstream' guys have been really worked on
> >> > product?
> > I doubt those "let's not work upstream" have been in this business for
> > as long as those of us who say "work upstrem first" have :)
> 
> 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.

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

> > Fine, you can ignore us, but realize that it will cost you time and
> > money to _not_ work upstream.  We are just trying to help you out...
> 
> Sorry to give you this impression, but that's not what I mean. To save
> mobile industry guys' time and give more help should be better than give
> more pressure on them.

We have given them lots of help, we gave them a whole kernel, and
another company gave them a whole operating system for free.  What more
do they want? :)

thanks,

greg k-h

  reply	other threads:[~2016-09-21 15:28 UTC|newest]

Thread overview: 122+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-01  2:01 [Ksummit-discuss] [Stable kernel] feature backporting collaboration Alex Shi
2016-09-02  1:25 ` Levin, Alexander
2016-09-02  2:43   ` Stephen Hemminger
2016-09-02  9:59     ` Mark Brown
2016-09-02  9:54   ` Mark Brown
2016-09-02 10:16     ` [Ksummit-discuss] [LTSI-dev] " Geert Uytterhoeven
2016-09-02 14:42     ` [Ksummit-discuss] " James Bottomley
2016-09-02 14:55       ` Rik van Riel
2016-09-02 15:04         ` James Bottomley
2016-09-02 15:39           ` Rik van Riel
2016-09-02 17:06       ` Bird, Timothy
2016-09-05  1:45         ` NeilBrown
2016-09-05 11:04           ` Mark Brown
2016-09-05 22:44             ` NeilBrown
2016-09-06  0:57               ` Mark Brown
2016-09-06  5:41                 ` NeilBrown
2016-09-08 18:33               ` [Ksummit-discuss] [LTSI-dev] " Bird, Timothy
2016-09-08 22:38                 ` NeilBrown
2016-09-09 11:01                   ` Mark Brown
2016-09-09 22:17                     ` NeilBrown
2016-09-12 17:37                       ` Mark Brown
2016-09-13  7:46                         ` NeilBrown
2016-09-13 17:53                           ` Mark Brown
2016-09-02 18:21       ` [Ksummit-discuss] " Olof Johansson
2016-09-02 23:35         ` Mark Brown
2016-09-03  5:29         ` Guenter Roeck
2016-09-03 10:40           ` Mark Brown
2016-09-04  0:10         ` Theodore Ts'o
2016-09-04  8:34           ` gregkh
2016-09-04 22:58           ` Amit Kucheria
2016-09-04 23:51             ` Theodore Ts'o
2016-09-05 12:58               ` Mark Brown
2016-09-05 11:11             ` Mark Brown
2016-09-05 14:03               ` Theodore Ts'o
2016-09-05 14:22                 ` Laurent Pinchart
2016-09-06  0:35                   ` Mark Brown
2016-09-06 15:30                     ` James Bottomley
2016-09-06 19:44                       ` gregkh
2016-09-06 22:20                         ` Mark Brown
2016-09-06 22:34                           ` James Bottomley
2016-09-08 18:55                             ` Bird, Timothy
2016-09-08 19:19                               ` gregkh
2016-09-09 10:45                                 ` Mark Brown
2016-09-09 11:03                                   ` gregkh
2016-09-09 11:48                                     ` Mark Brown
2016-09-06 23:23                       ` Mark Brown
2016-09-06 13:34                   ` Catalin Marinas
2016-09-06 16:24                     ` Bartlomiej Zolnierkiewicz
2016-09-06 16:25                     ` Guenter Roeck
2016-09-06 22:39                       ` Mark Brown
2016-09-07  8:33                       ` Jan Kara
2016-09-07  8:41                         ` Jiri Kosina
2016-09-07 18:44                           ` Mark Brown
2016-09-08 17:06                             ` Frank Rowand
2016-09-09 10:32                               ` Mark Brown
2016-09-09 15:21                         ` Alex Shi
2016-09-12 15:34                         ` Christoph Hellwig
2016-09-06 16:46                     ` Olof Johansson
2016-09-08  8:34                       ` Linus Walleij
2016-09-08  8:55                         ` Vinod Koul
2016-09-09 14:32                           ` Rob Herring
2016-09-09 14:23                         ` Rob Herring
     [not found]                     ` <2181684.5VzIQ6DWv4@amdc1976>
2016-09-07  9:32                       ` Catalin Marinas
2016-09-07 13:07                         ` Bartlomiej Zolnierkiewicz
2016-09-07 18:49                         ` Mark Brown
2016-09-09 15:06                         ` Alex Shi
2016-09-02 23:29       ` Mark Brown
2016-09-02 19:16     ` Levin, Alexander
2016-09-03  0:05       ` Mark Brown
2016-09-05  9:28         ` Laurent Pinchart
2016-09-21  6:58           ` Alex Shi
2016-09-21  9:23             ` gregkh
2016-09-21 14:52               ` Alex Shi
2016-09-21 15:28                 ` gregkh [this message]
2016-09-21 18:50                   ` Mark Brown
2016-09-22  3:15                   ` Alex Shi
2016-09-21 18:22               ` Mark Brown
2016-09-21 18:54                 ` Linus Walleij
2016-09-21 19:52                 ` Theodore Ts'o
2016-09-22  0:43                   ` Mark Brown
2016-09-22  5:20                 ` gregkh
2016-09-22 12:56                 ` Laurent Pinchart
2016-09-22 16:22                   ` Mark Brown
2016-09-22 22:14                     ` Theodore Ts'o
2016-09-23 12:28                       ` Laurent Pinchart
2016-09-23 13:27                         ` [Ksummit-discuss] [LTSI-dev] " Alex Shi
2016-09-23 13:40                           ` Laurent Pinchart
2016-09-23 14:40                       ` [Ksummit-discuss] " Mark Brown
2016-09-21 13:56             ` Theodore Ts'o
2016-09-21 15:23               ` Alex Shi
2016-09-21 15:33                 ` gregkh
2016-09-21 19:16                   ` Mark Brown
2016-09-02 13:47 ` Theodore Ts'o
2016-09-02 19:31   ` Levin, Alexander
2016-09-02 19:42     ` gregkh
2016-09-02 20:06       ` Levin, Alexander
2016-09-03  2:04   ` Mark Brown
2016-09-06  7:20   ` [Ksummit-discuss] [LTSI-dev] " Tsugikazu Shibata
2016-09-10 12:00     ` Theodore Ts'o
2016-09-12 16:27       ` Mark Brown
2016-09-12 17:14         ` Greg KH
2016-09-12 23:45           ` Mark Brown
2016-09-13  3:14             ` Theodore Ts'o
2016-09-13 10:14               ` Mark Brown
2016-09-13 13:19               ` Levin, Alexander
2016-09-13  6:19             ` Greg KH
2016-09-13 10:38               ` Mark Brown
2016-09-13 12:09                 ` Greg KH
2016-09-13 12:20                   ` Josh Boyer
2016-09-13 13:12                     ` Greg KH
2016-09-13 16:23                       ` Bird, Timothy
2016-09-13 19:02                       ` Mark Brown
2016-09-14 14:47                       ` Alex Shi
2016-09-20  5:15                       ` Tsugikazu Shibata
2016-09-21  8:46                         ` Alex Shi
2016-09-13 12:25                 ` Geert Uytterhoeven
2016-09-13 19:21                   ` Mark Brown
2016-09-14  1:49                     ` Greg KH
2016-09-14  3:00                       ` Guenter Roeck
2016-09-12  4:12     ` Alex Shi
2016-09-12 16:09       ` Masami Hiramatsu
2016-09-13  2:39         ` Alex Shi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160921152819.GA25212@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=alex.shi@linaro.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=ltsi-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.