Re: [Ksummit-discuss] [LTSI-dev] [Stable kernel] feature backporting collaboration

[Alex Shi <alex.shi@linaro.org>]

On 09/06/2016 03:20 PM, Tsugikazu Shibata wrote:
> It seems too late but Here I would like to comment from LTSI project's stand point:
> We were started LTSI project similar view as above that is:
> - LTSI is based on upstream first policy. We are providing a chance to
> merge vendor-required patches on top of LTS but patches need to be
> in -next or merged in later upstream and back ported to LTS.
> Majority of LTSI's additional patches are drivers but sometimes tools or 
> new features may proposed. Such patches are reviewed in case by case 
> basis but should be self-contained.
> - We are approaching to SoC vendors and device manufactures to 
> convince their in-house patches to be upstream. It seems that
> SoC vendors can create their own fork for their customers but
> providing a chance to merge their patches on top of LTS as LTSI will
> make some motivation to merge such patches into upstream as long 
> term view. Yes, We hope our activities may reduce the problem 
> discussed in this thread in longer term. 
> Actually, some of SoC vendors would send us their patches 
> backported from upstream. We will continue to discuss with SoCs and 
> device manufactures to solve the problem.
> - Also, some member of LTSI is employee of companies and they are
> testing hard for LTSI kernel before the release. Those fixes are providing
> to upstream not just LTSI actually. We see LTSI is being one of activity 
> of filling the gap between companies and community to create the kernel 
> used for the companies and industry.

Thanks for Tsugikazu's explanation of LTSI!
LSK follows the very similar rules as LTSI, if anyone like to look into
LSK's policies: https://wiki.linaro.org/LSK
>From 'LSK INCLUSION CONSIDERATIONS' chapter.

Compare to LTSI, LSK has newer LTS, and more upstream features
backporting which requested by many SoC vendors. Apparently these are
needed widely in industry. And the separately feature branch give more
feasibility on feature selection to user. If don't like any features
branches, That just left pure LTS.

BTW, someone worried non-upstream feature wasn't in LSK mainline. We
setup rules to isolated them.

=====
The LSK is meant for stability, not early access, thus normal requested
features should be present in an upstream kernel (committed in the
mainline kernel, or on a clear path to upstream, i.e. merged into
linux-next or applied to a maintainer tree) prior to the request.
Exception rules for few extra features which are necessary and not
merged in upstream yet:
stay out of the LSK mainline by a separate branch, but easy merged into LSK
sponsor Linaro group or member company need providing source code and
response for quality
=====

> 
> Finally, A request to the community from LTSI's stand point is:
> We want to have some process to be expected; How or about when 
> LTS would be released. So that companies can easier to create their plan 
> to use LTS and that will cause more user can use stable and secure
> kernel.