From: Greg KH <greg@kroah.com>
To: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: stable@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: -longterm kernels
Date: Sat, 7 May 2011 08:40:40 -0700 [thread overview]
Message-ID: <20110507154040.GC23672@kroah.com> (raw)
In-Reply-To: <20110507145503.GA2276@redhat.com>
On Sat, May 07, 2011 at 04:55:03PM +0200, Stanislaw Gruszka wrote:
> On Thu, May 05, 2011 at 08:25:01AM -0700, Greg KH wrote:
> > > BTW, Greg, perhaps -logterm releasing policy should be revised somehow.
> > > Currently we have .32, .33, .34, .35 -longterm, what is kind a much.
> >
> > It's not "much" if you rely on that kernel version, right?
>
> Yes, but maybe would be better if they do not relay on some versions in
> long term manner, and i.e. .33 users would use .32 and .34 users would
> use .35 instead?
You would think, but those kernels are being maintained for a reason
that those people feel matter.
> So perhaps having well defined kernel.org rule/policy about which kernel
> version will be longterm updated, will allow distributions/users choose
> the same kernel version for they long live project. What in consequence
> will result that they together will have better tested and supported
> kernel.
Perhaps, but we've been doing just fine so far for over 5 years, right?
:)
> > Nor if you aren't doing the work, no one forces anyone to backport any
> > patches to older kernels if they don't want to. The above patch was
> > asked to be backported as the original submitter wanted it there, hence
> > my asking for them to do it if they really wanted it.
>
> Sure. Actually I didn't want to complain about that. When I wrote
> "less work", I rather meant "less work" for these who want to fix old
> kernels bugs for whatever reason.
>
> > > If
> > > I could suggest something, would be nice to have longterm chosen
> > > versions predictable and constants i.e. one from every 3 kernel
> > > releases, like .35, .38, .41 ... . That would make distributions, that
> > > try to do release every half year very happy, because they will know
> > > what kernel to choose, which will be widely supported and tested.
> >
> > The distros are the ones doing this -stable and -longterm work, so they
> > very well know exactly what is going on.
>
> Hmm, I consider -stable rather as kernel.org project. People from
> different distributions/communities cc patches to -stable, review them,
> do backports ...
>
> > If they want to have a
> > specific kernel version marked as "-longterm", then they do the work to
> > do so.
> >
> > What happens in the future, with future releases, is always unknown, as
> > hey, it's the future :)
> >
> > So I really fail to understand what you are asking for here.
>
> We have -stable rule that released kernel will be be updated until next
> release - about 2 months.
It's an informal rule, yes.
> I would like to add rule about -longterm kernels. That it have to be one
> form every 3 release, it will be updated about half a year - until next
> -longterm (with possibility of longer updates). Or some similar rule.
Nope, I'm not making such a rule, as you are trying to tell others what
to do here. And I'm not going to do that.
Also, I'm not going to promise to do such maintainership either, and
last I checked, no distro is going to do that either.
> That version should be good choice for distros and any other long live
> project, and natural candidate for "real longterm" i.e. a few years
> updated/supported kernel version.
Again, distros know exactly what is going on here, they don't need
anything new.
sorry,
greg k-h
next prev parent reply other threads:[~2011-05-07 15:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201105030110.p431A5W0005426@hera.kernel.org>
[not found] ` <20110504223605.GA5967@kroah.com>
2011-05-05 14:58 ` -longterm kernels (Was: Re: [stable] Patch Upstream: iwlwifi: fix skb usage after free) Stanislaw Gruszka
2011-05-05 15:17 ` [stable] -longterm kernels (Was: " Willy Tarreau
2011-05-05 15:25 ` -longterm kernels (Was: Re: [stable] " Greg KH
2011-05-07 14:55 ` -longterm kernels Stanislaw Gruszka
2011-05-07 15:40 ` Greg KH [this message]
2011-05-07 15:57 ` Stanislaw Gruszka
2011-05-07 19:01 ` Greg KH
2011-05-09 9:18 ` Stanislaw Gruszka
2011-05-08 5:09 ` Mike Galbraith
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=20110507154040.GC23672@kroah.com \
--to=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sgruszka@redhat.com \
--cc=stable@kernel.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.