All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: david@lang.hm
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
Subject: Re: Future of the -longterm kernel releases (i.e. how we pick them).
Date: Mon, 15 Aug 2011 07:21:42 -0700	[thread overview]
Message-ID: <20110815142142.GC11358@kroah.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1108150007100.24266@asgard.lang.hm>

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

> I hope my midnight rambling makes some sort of sense :-)

It did, thanks for the response.

greg k-h

  reply	other threads:[~2011-08-15 14:23 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 [this message]
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
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=20110815142142.GC11358@kroah.com \
    --to=greg@kroah.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=david@lang.hm \
    --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 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.