From: Willy Tarreau <w@1wt.eu>
To: Greg KH <greg@kroah.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
Subject: Re: [Stable-review] Future of the -longterm kernel releases (i.e. how we pick them).
Date: Mon, 15 Aug 2011 09:33:09 +0200 [thread overview]
Message-ID: <20110815073309.GB18367@1wt.eu> (raw)
In-Reply-To: <20110815041524.GA7578@kroah.com>
Hi Greg,
On Sun, Aug 14, 2011 at 09:15:24PM -0700, Greg KH wrote:
> As I'm giving a talk about the -stable and -longterm kernels this week
> at LinuxCon in Vancouver, and I've been talking with a lot of different
> people about the future of the -longterm kernels, here's some thoughts
> as to what I'm considering:
(...)
> Thoughts?
I think this is all good, and knowing in advance what next kernel will
be picked will help a lot of users because they'll be able to focus on
a given version.
I just have one comment about the 2-years : new devices generally ship
with something which is expected to be stable, so they won't ship with
the shiny new 2-digit kernel that was just released. This means that a
two-years lifecycle for the longterm kernels will allow less than 2
years of life for the device.
But possibly there are several types of products :
- the ones where an upgrade may be forced on the user about once a
year, so that the kernel can be between 1 and 2-years old
- the ones that have to live longer without upgrades
I'm realizing that the second type is mostly the case for products
that are not easy to validate and are kept as-is without update as
long as they're supported, which is common in the network appliances
world (this is the reason I picked 2.6.27 ;-)).
Also, since your kernels are pretty stable after 2 years, updates are
quite rare and generally of minor importance. This is also the time I
choose to pick them for use in products where planning a reboot takes
weeks and an upgrade takes many months (I even know some people who are
currently ordering hardware to deploy 2.4). So it's likely that in 6
months I'll be interested in an almost frozen 2.6.32, and I will then
propose you to take it over and prolong its life when you drop it.
And in the end, I think this development model makes a lot of sense :
- developers need a fast moving target
- desktop users need something up to date with latest drivers and
don't need the best stability => latest release or -stable are OK
- most servers are happy with -stable (mine are)
- distros need to focus on a recent -longterm and will contribute
to its stability
- some products need to ship with a very stable -longterm with
rare updates
You're interested in the 4th category above and I'm in the 5th. So
in the end, I think that your proposal fits your expected target
perfectly well, and that if I want it to fit mine, I'll just have
to extend it myself as we've done till now. So that sounds good !
Thanks,
Willy
next prev parent reply other threads:[~2011-08-15 7:43 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 ` Willy Tarreau [this message]
2011-08-15 14:18 ` [stable] [Stable-review] " 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=20110815073309.GB18367@1wt.eu \
--to=w@1wt.eu \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--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