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

[Greg KH <greg@kroah.com>]

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

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

thanks,

greg k-h