Re: Future of the -longterm kernel releases (i.e. how we pick them).

[Brian Swetland <swetland@google.com>]

On Tue, Aug 23, 2011 at 9:57 PM, Greg KH <greg@kroah.com> wrote:
> On Wed, Aug 17, 2011 at 10:33:05AM -0700, Brian Swetland wrote:
>> As far as long-term kernels goes, from the Android perspective we
>> strongly prefer to snap up to the most recent released kernel on every
>> platform/device release.  I prefer to be as up to date on bugfixes and
>> features from mainline as possible and minimize the deltas on our
>> stack 'o patches as much as possible.
>
> That's good to hear.
>
>> We've been getting more aggressive about merging in the -rc#s and then
>> rebasing on the final during development (before final stabilization
>> freeze for a release) in the last year or so, and it seems to work
>> pretty well.
>
> Is your kernel git tree public during this merge cycle so that others
> can track it?  I tried to dig through android.kernel.org but there are a
> lot of different kernel trees there :(

We really need a "which branch is which" quick guide that's easily
findable.  kernel/common is always where our generic patch stack
lives, and it looks like android-3.0 is the most recent (which has
3.0.1 merged in).

http://android.git.kernel.org/?p=kernel/common.git;a=summary

>> Not all OEMs or silicon vendors are as comfortable with this approach
>> and I expect some would welcome a long term tree they can count on to
>> get critical fixes for, though.  Device release teams (even our own,
>> for lead devices we work on) are notoriously risk-averse (often for
>> good reasons), and tend to get really nervous when they see the total
>> change count or diff stat for pulling up to a new kernel release close
>> to "final rom" for a product.
>
> That's understandable.
>
> So that kind of means they would like such a longterm tree, but they
> have the problem that your patches move forward to a newer kernel, but
> are not maintained for that longterm kernel.  Are they responsible for
> maintaining this themselves then, or do you help with providing your
> patchset on top of all of the different kernel versions that the OEMs
> and others need?

So far the silicon vendors have been doing more of the longer term
kernel stuff, as it better matches their model of providing "boxed"
stable BSPs of some sort.  It might make sense for us to ensure
backports of fixes for core patches (our common tree) are available
for the LT kernels, but we are unlikely to have the necessary staff to
maintain LT trees for every SoC we interact with.

Brian