ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Alex Shi <alex.shi@linaro.org>
To: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.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: Thu, 22 Sep 2016 11:15:10 +0800	[thread overview]
Message-ID: <57E34CBE.6080907@linaro.org> (raw)
In-Reply-To: <20160921152819.GA25212@kroah.com>


On 09/21/2016 11:28 PM, gregkh@linuxfoundation.org wrote:
> 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.

Thanks info, Greg!

I wish every company could have engineers as good as you. Then there is
no needs on LTSI or LSK like things.

But the fact is much of company still need some help on kernel. Even in
Meego project, most of vendors can not do well as your team, they still
need 'reference kernel' and keep much out of tree code.

http://www.allaboutmeego.com/news/item/12477_MeeGo_kernel_policy_announceme.php
--
Correspondingly, maintainers of "kernel adaptations" will be expected to
backport features from the main MeeGo reference kernel to their own
kernels, to protect the reputation of MeeGo and maintain functionality
for end-users.
--
BTW, meego.com disappeared, so I can not find full kernel policy of
meego now.

> 
>> 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 :)

That depends on how you define 'well'. :)
Yes, they has no capability to polish software system in ideal status.
but they give people more choices on smart phone. Not only iphone.

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

Sorry. I can not get more detailed info from them.

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

Actually, I have no much good idea on helping them. But seems LTSI/LSK
is kind of thing would give some help.

Open source is a large world with many players which isn't good enough.

The interesting thing is, we always play the same role as you here to
our members, to encourage them to involve more in community, to use
latest kernel/LTS as they can. But they need time and more practice.

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

Good to know. Thanks!

> 
>>> 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? :)
> 

Shortly here, LTSI/LSK. For long term, the capability for upstream work.

Well, the LTSI/LSK do save their time and release more engineers to
upstream work.

  parent reply	other threads:[~2016-09-22  3:15 UTC|newest]

Thread overview: 122+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-01  2:01 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
2016-09-21 18:50                   ` Mark Brown
2016-09-22  3:15                   ` Alex Shi [this message]
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=57E34CBE.6080907@linaro.org \
    --to=alex.shi@linaro.org \
    --cc=gregkh@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox