On Mon, Jul 11, 2016 at 10:20 AM, Theodore Ts'o <tytso@mit.edu> wrote:

> On Mon, Jul 11, 2016 at 10:15:06AM -0700, Dmitry Torokhov wrote:
> >
> > Cherry picking a commit from a branch/remote is much nicer than fetching
> > a part of [quilt based?] patch queue from git, unless I misunderstand
> > what you are proposing.
>
> The reason why I'm wondering whether or not quilt based might be
> better is because if it turns out that a patch introduces a
> regression, with a quilt based system the patch can be *dropped*, or
> revised in place.
>
> When you do a cherry-pick, you depend on the BSP kernel maintainer
> figuring out that a commit was later reverted, or fixed by a later
> commit that might have a different name, and which doesn't make it
> obvious that if you take commit 'A', you REALLY want to take commits
> 'B' and 'C' as well....
>

Ted, you keep using the term "BSP kernel maintainer". Mind clarifying what
you mean with it? I don't want to be picky, I just want to avoid
miscommunication.

BSP kernels are a small subset of downstream kernels. A BSP is often the
"evil vendor tree" that we keep seeing people complain about. They rarely
see updates on base versions (i.e. many are still on 3.10 and 3.18).

Some downstream _product_ kernels are based on BSP kernels, some are not.

Typical examples of those who _are_ based on BSPs tend to be $random
android device out there, where an OEM takes what the SoC manufacturer
gives them, does minimal changes and ships it.

Examples who are _not_ based on BSPs tend to be Android's own kernels
(Nexus devices), Chrome OS, and many inhouse kernel trees out there.

I think most people engaged in this discussion are working on non-BSP
downstream kernel trees.


-Olof