lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 24 Sep 2010 06:19:14 -0700
From:	Greg KH <greg@...ah.com>
To:	Geoffrey Said <geoffrey@...com>
Cc:	stable@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: Long maintenance kernel versions.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ