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]
Message-ID: <AANLkTimnUrWQ6qrUi_91mrZ3BF8e91997ScKY6OMSBSk@mail.gmail.com>
Date:	Fri, 24 Sep 2010 15:30:52 +0200
From:	Geoffrey Said <geoffrey@...com>
To:	Greg KH <greg@...ah.com>
Cc:	stable@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: Long maintenance kernel versions.

Thanks for the info.  Unfortunately I missed the .32 announcement as I
am not always working on kernel integration.

Are there any future planned versions for long term maintenance, like
say the .36?

Thanks again.

On Fri, Sep 24, 2010 at 3:19 PM, Greg KH <greg@...ah.com> wrote:
> 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
>



-- 
Geoffrey Said
Software Developer
2X Software - http://www.2x.com
Developers of virtual computing software
2X VirtualDesktopServer - 2X ApplicationServer - 2X LoadBalancer - 2X
ThinClientServer

Tel: +356 2258 3800
Fax:+356 2137 7078
--
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