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

[Brian Swetland]

On Wed, Aug 17, 2011 at 6:21 AM, Mark Brown
<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Aug 16, 2011 at 09:58:56PM -0700, Greg KH wrote:
>> On Tue, Aug 16, 2011 at 04:01:57PM -0700, Tim Bird wrote:
>
>> > The other major out-of-tree patches we usually integrate are
>> > 1) Android
>
>> I would love to get some feedback/contacts with the Android teams to
>> talk about this with them. ÂIf anyone knows anyone I should talk to
>> here, please let me know.
>
> Brian Swetland and Arve HjÃnnevÃg should be able to point you at the
> right people if they aren't themselves the right people.
>
> [Sorry if my software has mangled your name Arve]

(something ate the final 'g' (fixed above) but otherwise his name
seems to have survived)

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.

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.

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.

Brian

(apologies to anyone who got this twice, gmail snafu with html
formatted email. I should use mutt for lkml...)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/