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

["Levin, Alexander" <alexander.levin@verizon.com>]

On Wed, Aug 31, 2016 at 10:01:13PM -0400, Alex Shi wrote:
> Hi All,
> 
> I am a Linaro stable kernel maintainer. Our stable kernel is base on LTS
> plus much of upstream features backporting on them. Here is the detailed
> info of LSK: https://wiki.linaro.org/LSK
> https://git.linaro.org/?p=kernel/linux-linaro-stable.git
> 
> These kind of backporting features are requested by many LSK members
> which most are leading ARM product vendors. LSK target on the feature
> backporting collaboration, to reduce the duplicate work on that. Current
> LTSI: https://ltsi.linuxfoundation.org/what-is-ltsi, has
> similar target for backporting collocation. but there are still couples
> problems.
> 
> 1, LTSI is focus on board support more than feature backporting
> 
> 2, ltsi kernel version 3.10/3.14/4.1 is older than LTS and LSK 3.18/4.1/4.4.
> 
> 3, merge everything together isn't good for some users and can not give
> user option to select preferred kernel feature. On the contrary, each of
> feature backported separately on latest LTS in LSK, user can just pick
> their wanted features and merge them for their own kernel.
> 
> 4, all vendor specific driver in one branch get complains and developing
> status make it hard to handle changes in a fast-forward stable kernel.
> 
> As to LSK, although most feature are ARM related, but LSK also provide
> some common feature which works on other archs, like cgroupv2, RO-vDSO,
> KASAN, PAX_USERCOPY, etc. I believe this common backporting is also
> useful for common industries.
> If so, could we call a better way for feature backporting collaboration?

I really disagree with this approach. I think that backporting board support
like what LTSI does might make sense since it's self contained, but what LSK
does is just crazy.

Stable kernels have very strict restrictions that are focused on not taking
commits that have high potential to cause unintended side effects, incorrect
interactions with the rest of the kernel or just introduce new bugs.

Mixing in new features that interact with multiple subsystems is a recipe for
disaster. We barely pull off backporting what looks like trivial fixes, trying
to do the same for more than that is bound be broken.

As an alternative, why not use more recent stable kernels and customize the
config specifically for each user to enable on features that that specific
user wants to have.

The benefit here is that if used correctly you'll get to use all the new shiny
features you want on a more recent kernel, and none of the things you don't
want. So yes, you're upgrading to a newer kernel all the time, but if I
understant your use-case right it shouldn't matter too much, more so if
you're already taking chances on backporting major features yourself.

-- 

Thanks,
Sasha