public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <ben@decadent.org.uk>
To: Greg KH <greg@kroah.com>
Cc: david@lang.hm, linux-kernel@vger.kernel.org,
	stable-review@kernel.org, akpm@linux-foundation.org,
	torvalds@linux-foundation.org, stable@kernel.org,
	alan@lxorguk.ukuu.org.uk
Subject: Re: [Stable-review] Future of the -longterm kernel releases (i.e. how we pick them).
Date: Tue, 16 Aug 2011 03:26:56 +0100	[thread overview]
Message-ID: <1313461616.2981.92.camel@deadeye> (raw)
In-Reply-To: <20110815142142.GC11358@kroah.com>

[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]

On Mon, 2011-08-15 at 07:21 -0700, Greg KH wrote:
> On Mon, Aug 15, 2011 at 12:21:59AM -0700, david@lang.hm wrote:
> > rather than having a hard schedule (the first kernel released after
> > July 1 each year for example I know this is not the exact proposal),
> > I think that it would be better to pick the -longterm kernel a few
> > months after it has been released (3.4 is looking very good, the
> > normal minor driver fixes in -stable, but no fundamental regressions
> > have been reported, it's the new -longerm kernel for example)
> > 
> > doing so doesn't give the predictability that some people will want
> > in knowing that their September release will always have a fresh new
> > -longerm kernel, but I think the result would be better -longterm
> > kernels. However, to get the information about how good the kernels
> > are, I think that the -stable timeframe would need to be extended to
> > give the kernels time to settle and gather reports. I would then
> > suggest scheduling that once a year you look at the last couple
> > -stable kernels and pick one of them rather than designating the new
> > -longterm kernel ahead of time.
> 
> Yes, that's a very good idea.  I've seen problems in the past when
> distros have made a time-based decision to pick a kernel version and
> then the problems that this can cause if it happens that a subsystem
> really had issues for that release.
> 
> So yes, I'll take a look at the bug reports and how things are working
> out to pick the next -longterm.  I'll also take into consideration any
> companies/major users that are going to be using that release as well,
> so it greatly behooves people to talk to me about their plans (hint,
> hint...)
[...]

This might be a good discussion to have at Kernel Summit, if enough
distro people are going to be there.

The next stable release of Debian will have a feature-freeze in June
2012, so we need to make a choice some time before then.  However I know
that Ubuntu will need to make a decision rather earlier for the 12.04
LTS release.

Are any other distributions aiming to make long-term-supported releases
in 2012?

Also, in Debian we just added an 'rt' build of the kernel using the
PREEMPT_RT patches.  We don't want to use different upstream versions as
a basis for specific builds, so if we're going to include PREEMPT_RT in
a stable distribution release we would ideally want to see some interest
in maintaining this patchset on top of the longterm series.  (Hopefully
it's going to be significantly smaller by then, of course.)

Ben.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2011-08-16  2:27 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     ` Ben Hutchings [this message]
2011-08-16  2:56       ` [stable] [Stable-review] " 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
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=1313461616.2981.92.camel@deadeye \
    --to=ben@decadent.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=david@lang.hm \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable-review@kernel.org \
    --cc=stable@kernel.org \
    --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