public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Tim Bird <tbird20d@gmail.com>
Cc: 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
Subject: Re: Future of the -longterm kernel releases (i.e. how we pick them).
Date: Tue, 16 Aug 2011 21:58:56 -0700	[thread overview]
Message-ID: <20110817045856.GB4936@kroah.com> (raw)
In-Reply-To: <CA+bK7J7_EKdQACnoJGWkd4asH+096SJ-gjEvsnjmRX6Dmc6dpA@mail.gmail.com>

On Tue, Aug 16, 2011 at 04:01:57PM -0700, Tim Bird wrote:
> >Greg KH wrote:
> > To keep this all out in the open, let's figure out what to do here.
> > Consumer devices have a 1-2 year lifespan, and want and need the
> > experience of the kernel community maintaining their "base" kernel for
> > them.  There is no real "enterprise" embedded distro out there from what
> > I can see.  montaVista and WindRiver have some offerings in this area, but
> > they are not that widely used and are usually more "deep embedded".
> > There's also talk that the CELF group and Linaro are wanting to do
> > something on a "longterm" basis, and are fishing around for how to
> > properly handle this with the community to share the workload.  Android
> > also is another huge player here, upgrading their kernel every major
> > release, and they could use the support of a longterm kernel as well.
> 
> Well I certainly hope that there's more participation on sharing the
> workload by embedded companies than there has historically been.
> I'm not at LinuxCon this week, but I want to follow up with you
> (maybe at KS?) on good ways that CE companies can help with
> this effort.

There is a BOF this week at LinuxCon with the CE companies about this
topic, and I've been talking with them about this as well, so if anyone
is there and interested, we can talk about it then.

And yes, ELC/KS/LinuxCon Europe is also a good place to discuss it as
well.

> That said, I echo the concerns about version selection.  It would be
> good to have a "settle" period longer than 1 stable release for selecting
> a kernel (but then again, we don't want to wait too long to pick each
> longterm release).

I understand, and will be working on this.  I'm trying to talk to
everyone I can about their plans for support and products to try to
determine this, and will see how it goes.

> Also, the more people using a particular LTS kernel, the better. In the past
> the embedded guys didn't coordinate well enough with other parties.  If
> we could get enterprise, desktop and embedded on a single LT release, that
> would be really nice.  I'm not sure how you're keeping track of interested
> parties, but if there's a mailing list (besides 'stable') let me know so I can
> sign up.

stable is the best place for this.  Or emails/phone calls/hallway
discussions with me as well.  Note, I also have the ability to sign NDAs
if needed.

> One specific issue I have is support for PREEMPT_RT, so that's a big
> factor in selecting Sony kernel versions.  Thus, coordinating with the
> RT patchset kernel versions is important to me.  Currently
> that would mean 3.0 is a good candidate.

3.0 is looking like a good candidate, but we haven't seen 3.1 yet :)

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

thanks,

greg k-h

  reply	other threads:[~2011-08-17  5:00 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 [this message]
2011-08-17 13:21     ` Mark Brown
2011-08-17 17:33       ` Brian Swetland
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=20110817045856.GB4936@kroah.com \
    --to=greg@kroah.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox