From: Greg KH <gregkh@suse.de>
To: "Randy.Dunlap" <rdunlap@xenotime.net>
Cc: 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: Sat, 28 Jan 2006 21:34:58 -0800 [thread overview]
Message-ID: <20060129053458.GA9293@suse.de> (raw)
In-Reply-To: <20060128205701.5b84922e.rdunlap@xenotime.net>
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...
thanks,
greg k-h
next prev parent reply other threads:[~2006-01-29 5:35 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 [this message]
2006-01-29 6:09 ` Willy Tarreau
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=20060129053458.GA9293@suse.de \
--to=gregkh@suse.de \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=chuckw@quantumlinux.com \
--cc=davej@redhat.com \
--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