From: Willy Tarreau <willy@w.ods.org>
To: Greg KH <gregkh@suse.de>
Cc: "Randy.Dunlap" <rdunlap@xenotime.net>,
Chuck Wolber <chuckw@quantumlinux.com>,
jmforbes@linuxtx.org, linux-kernel@vger.kernel.org,
stable@kernel.org, zwane@arm.linux.org.uk, tytso@mit.edu,
davej@redhat.com, torvalds@osdl.org, akpm@osdl.org,
alan@lxorguk.ukuu.org.uk
Subject: Re: [patch 0/6] 2.6.14.7 -stable review
Date: Sun, 29 Jan 2006 07:09:46 +0100 [thread overview]
Message-ID: <20060129060946.GX7142@w.ods.org> (raw)
In-Reply-To: <20060129053458.GA9293@suse.de>
On Sat, Jan 28, 2006 at 09:34:58PM -0800, Greg KH wrote:
> On Sat, Jan 28, 2006 at 08:57:01PM -0800, Randy.Dunlap wrote:
> > On Sat, 28 Jan 2006 20:52:46 -0800 (PST) Chuck Wolber wrote:
> >
> > > On Sat, 28 Jan 2006, Justin M. Forbes wrote:
> > >
> > > > On Sat, Jan 28, 2006 at 08:30:25PM -0800, Chuck Wolber wrote:
> > > > >
> > > > > Please correct me if I'm wrong here, but aren't we supposed to stop doing
> > > > > this for the 2.6.14 release now that 2.6.15 is out?
> > > >
> > > > I don't see a problems with doing additional stable releases for any
> > > > kernel, I just wouldn't commit to supporting any specific number of
> > > > releases. Basically if people send enough patches to warrant a
> > > > review/release there is obviously some interest. What is the harm?
> > >
> > > The harm is that stable release patches will eventually start being
> > > maintained and we'll have to add another stable release "dot" to the end
> > > of the growing width of the release version moniker. This stable branch
> > > was meant only for "one-off" fixes to a stable release, not for adding
> > > fixes upon fixes upon fixes that eventually turn into features that have
> > > to be maintained. A new stable release means we change our focus to it and
> > > ignore the old stable release.
> >
> > It's a 6-month sliding window for stable releases IIRC.
> > Maybe <stable@kernel.org> can add something like that to
> > Documentation/stable_kernel_rules.txt>.
>
> No, it's not a 6 month window, I released this because people sent us
> patches that they said should go into the 2.6.14-stable tree. And as
> people complained so much on lkml that we were dropping the old kernels
> too fast, I never thought that people would complain that we are
> maintaining older stuff that people seem interested in...
>
> And, odds are, it will probably be the last 2.6.14 stable kernel we (the
> stable team) release, unless something unusual happens...
>
> And, as always, anyone is free to take on maintaining any of the
> different kernel versions for as long as they wish.
>
> Does that help?
>
> Man, people complain when you don't maintain older kernels, and they
> complain when you do...
Greg, there will always be stupid people who don't understand the work
of others. These are the same type of people who won't understand at all
why there's a -stable branch. When I started 2.4-hf, I've been told
"you're dumb, 2.4 is dead". I'm very glad that you take care of people
who cannot easily upgrade to latest version, and I'm sure that a lot of
users are too.
> thanks,
>
> greg k-h
Thanks for keeping up the good work,
Willy
next prev parent reply other threads:[~2006-01-29 6:10 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060128015840.722214000@press.kroah.org>
2006-01-28 2:17 ` [patch 0/6] 2.6.14.7 -stable review Greg KH
2006-01-28 2:18 ` [patch 1/6] setting irq affinity is broken in ia32 with MSI enabled Greg KH
2006-01-28 2:18 ` [patch 2/6] [EBTABLES] Don't match tcp/udp source/destination port for IP fragments Greg KH
2006-01-28 2:18 ` [patch 3/6] [SPARC64]: Fix ptrace/strace Greg KH
2006-01-28 2:18 ` [patch 4/6] [SPARC64]: Fix sys_fstat64() entry in 64-bit syscall table Greg KH
2006-01-28 2:18 ` [patch 5/6] [NETFILTER]: Fix crash in ip_nat_pptp (CVE-2006-0036) Greg KH
2006-01-28 2:18 ` [patch 6/6] [NETFILTER]: Fix another crash in ip_nat_pptp (CVE-2006-0037) Greg KH
2006-02-08 12:35 ` Holger Eitzenberger
2006-02-10 4:47 ` [stable] " Greg KH
2006-02-10 4:57 ` Andrew Morton
2006-02-10 5:08 ` Greg KH
2006-02-10 8:07 ` Harald Welte
2006-01-29 4:30 ` [patch 0/6] 2.6.14.7 -stable review Chuck Wolber
2006-01-29 4:43 ` Justin M. Forbes
2006-01-29 4:52 ` Chuck Wolber
2006-01-29 4:57 ` Randy.Dunlap
2006-01-29 5:34 ` Greg KH
2006-01-29 6:09 ` Willy Tarreau [this message]
2006-01-29 7:36 ` Chuck Wolber
2006-01-29 7:11 ` Chuck Wolber
2006-01-29 7:58 ` Chuck Wolber
2006-01-29 4:45 ` Randy.Dunlap
2006-01-29 5:02 ` Chuck Wolber
2006-01-29 6:17 ` Willy Tarreau
2006-01-29 7:43 ` Chuck Wolber
2006-01-31 15:05 ` Krzysztof Halasa
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=20060129060946.GX7142@w.ods.org \
--to=willy@w.ods.org \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=chuckw@quantumlinux.com \
--cc=davej@redhat.com \
--cc=gregkh@suse.de \
--cc=jmforbes@linuxtx.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.net \
--cc=stable@kernel.org \
--cc=torvalds@osdl.org \
--cc=tytso@mit.edu \
--cc=zwane@arm.linux.org.uk \
/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