public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Greg KH <greg@kroah.com>
Cc: stable@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: -longterm kernels
Date: Sat, 7 May 2011 16:55:03 +0200	[thread overview]
Message-ID: <20110507145503.GA2276@redhat.com> (raw)
In-Reply-To: <20110505152501.GA14146@kroah.com>

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?

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.

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

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.

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.

Stanislaw

  reply	other threads:[~2011-05-07 14:54 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       ` Stanislaw Gruszka [this message]
2011-05-07 15:40         ` -longterm kernels Greg KH
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=20110507145503.GA2276@redhat.com \
    --to=sgruszka@redhat.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox