All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Swetland <swetland@google.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: "Greg KH" <greg@kroah.com>, "Tim Bird" <tbird20d@gmail.com>,
	linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
	akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk,
	stable-review@kernel.org, stable@kernel.org,
	tim.bird@am.sony.com, "Arve Hjønnevå" <arve@android.com>
Subject: Re: Future of the -longterm kernel releases (i.e. how we pick them).
Date: Wed, 17 Aug 2011 10:33:05 -0700	[thread overview]
Message-ID: <CANqkERC2eyy3SQ6_vJncvuMdi=Yu=O8mZoXkggkX1q_4=d+q7g@mail.gmail.com> (raw)
In-Reply-To: <20110817132114.GB10209@sirena.org.uk>

On Wed, Aug 17, 2011 at 6:21 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> 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...)

  reply	other threads:[~2011-08-17 17:33 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-15  4:15 Future of the -longterm kernel releases (i.e. how we pick them) Greg KH
2011-08-15  6:48 ` Jörg-Volker Peetz
2011-08-15  7:06   ` david
2011-08-15  7:16     ` Teck Choon Giam
2011-08-15  7:25       ` david
2011-08-15  7:38         ` Teck Choon Giam
2011-08-15  7:57         ` Jörg-Volker Peetz
2011-08-17 11:07       ` James Courtier-Dutton
2011-08-15  7:19   ` Jörg-Volker Peetz
2011-08-15  7:21 ` david
2011-08-15 14:21   ` Greg KH
2011-08-16  2:26     ` [Stable-review] " Ben Hutchings
2011-08-16  2:56       ` [stable] " Greg KH
2011-08-16  3:31         ` Ben Hutchings
2011-08-16  5:26     ` Daniel Taylor
2011-08-24 23:57       ` Greg KH
2011-08-15  7:33 ` [Stable-review] " Willy Tarreau
2011-08-15 14:18   ` [stable] " Greg KH
2011-08-15 15:04 ` [stable] " Tim Gardner
2011-08-16  2:09 ` [Stable-review] " Ben Hutchings
2011-08-16  2:57   ` [stable] " Greg KH
2011-08-16 19:26   ` Jeremiah C. Foster
2011-08-16 22:33     ` [stable] " Greg KH
2011-08-17 10:33       ` Jeremiah Foster
2011-08-17 20:20         ` david
2011-08-24  4:47           ` Greg KH
2011-08-24  4:46         ` Greg KH
2011-08-24 13:03           ` Jeremiah Foster
2011-08-16 23:01 ` Tim Bird
2011-08-17  4:58   ` Greg KH
2011-08-17 13:21     ` Mark Brown
2011-08-17 17:33       ` Brian Swetland [this message]
2011-08-24  4:57         ` Greg KH
2011-08-25  4:49           ` Brian Swetland
2011-08-26  0:03             ` Greg KH
2011-08-18  0:33     ` [Stable-review] " Ben Hutchings
2011-08-18 11:28       ` Pasi Kärkkäinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANqkERC2eyy3SQ6_vJncvuMdi=Yu=O8mZoXkggkX1q_4=d+q7g@mail.gmail.com' \
    --to=swetland@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arve@android.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable-review@kernel.org \
    --cc=stable@kernel.org \
    --cc=tbird20d@gmail.com \
    --cc=tim.bird@am.sony.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.