From: Greg KH <greg@kroah.com>
To: Geoffrey Said <geoffrey@2x.com>
Cc: stable@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Long maintenance kernel versions.
Date: Fri, 24 Sep 2010 06:19:14 -0700 [thread overview]
Message-ID: <20100924131914.GA1965@kroah.com> (raw)
In-Reply-To: <AANLkTinGJmAzdd=HOKZYSh69F6T9HMznOKW5BS90=Q-4@mail.gmail.com>
On Fri, Sep 24, 2010 at 07:10:09AM +0200, Geoffrey Said wrote:
> To whom it may concern.
>
> I would like to put forward the following questions. Hope that I am
> not making a fool of myself!
>
> How is the procedure by which a certain kernel version is declared as
> a long maintenance version?
There really isn't a set procedure yet.
> Is the version decided before or after the release of the stable kernel?
Sometimes after, sometimes before.
> And where can I check for planned long term maintenance versions?
You can ask.
Here's how the last 3 "long-term" releases came about:
.16 - turned out that my employeer was using it for an enterprise
kernel release, so it made my "day job" a lot easier to keep it
going for a longer-than-normal period of time. People liked
this, so it kept going.
.27 - Same as before.
.32 - Now things got interesting. Some kernel developers who "worked"
for different distros got together and talked about picking a
release that their distros could sync up on and become a
long-term released kernel. That ended up being the .32 kernel
and we planned it ahead of time. This resulted in all of the
major distros relying on this kernel for their releases.
And that's it. Pretty simple, but effective.
> I am asking the above questions because we are migrating our Linux OS
> to the 2.6.34 kernel and we have learned that this will not be
> actively maintained and we are advised to switch to the 35 one.
> Since a lot of effort has been put to migrate to the 2.6.34 kernel and
> a lot of testing has been done, it is frustrating to hear the above
> news.
You can always ask me ahead of time what is going on with this type of
thing, that's the best way. I am easy to get ahold of if you have
questions like this.
> From our point of view it would be nice to declare a version log term
> maintenance before or at least on release so that we can migrate
> between long-term kernels.
For .32, I did announce this ahead of time, perhaps you missed that.
Hope this helps,
greg k-h
next prev parent reply other threads:[~2010-09-24 13:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-24 5:10 Long maintenance kernel versions Geoffrey Said
2010-09-24 5:36 ` Américo Wang
2010-09-24 5:42 ` Geoffrey Said
2010-09-24 8:54 ` el es
2010-09-24 9:29 ` Américo Wang
2010-09-24 13:19 ` Greg KH [this message]
2010-09-24 13:30 ` Geoffrey Said
2010-09-24 13:48 ` Greg KH
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=20100924131914.GA1965@kroah.com \
--to=greg@kroah.com \
--cc=geoffrey@2x.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