linux-kernel - Re: [Stable-review] Future of the -longterm kernel releases (i.e. how we pick them).

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: <1313460542.2981.76.camel@deadeye>
Date:	Tue, 16 Aug 2011 03:09:02 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Greg KH <greg@...ah.com>
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	stable-review@...nel.org, stable@...nel.org,
	Debian kernel maintainers <debian-kernel@...ts.debian.org>
Subject: Re: [Stable-review] Future of the -longterm kernel releases (i.e.
 how we pick them).

On Sun, 2011-08-14 at 21:15 -0700, Greg KH wrote:
[...]
> Today:
> 
> Now that 2.6.32 is over a year and a half, and the enterprise distros
> are off doing their thing with their multi-year upgrade cycles, there's
> no real need from the distros for a new longterm kernel release.  But it
> turns out that the distros are not the only user of the kernel, other
> groups and companies have been approaching me over the past year, asking
> how they could pick the next longterm kernel, or what the process is in
> determining this.
> 
> To keep this all out in the open, let's figure out what to do here.
> Consumer devices have a 1-2 year lifespan, and want and need the
> experience of the kernel community maintaining their "base" kernel for
> them.

This timespan is both somewhat optimistic with respect to current
reality, and also rather depressing in that it sets a very low bar.  I
would hope that we don't collectively treat consumer electronics as
disposable and that responsible vendors would like to provide security
support for a lifetime of 5-10 years.  (But no, I don't think that's
easy.)

[...]
> Proposal:
> 
> Here's a first cut at a proposal, let me know if you like it, hate it,
> would work for you and your company, or not at all:
> 
> - a new -longterm kernel is picked every year.
> - a -longterm kernel is maintained for 2 years and then dropped.

This is nowhere near the maintenance lifetime for any of the vendors
that are following 2.6.32.y now:

Debian: ~3 years (stated as 1 year after next release)
Oracle: ??? (probably as long as anyone pays for it)
SUSE (SLES): 7 years
Ubuntu (LTS): 5 years

(and those distributions were released well after the original 2.6.32
release).  Given that we'll want to carry on sharing the maintenance
burden, it seems silly to set such an early cut-off date.

[...]
> This means that there are 2 -longterm kernels being maintained at the
> same time, and one -stable kernel.  I'm volunteering to do this work, as
> it's pretty much what I'm doing today anyway, and I have all of the
> scripts and workflow down.
[...]

I entirely understand that *you* don't want to be stuck maintaining
longterm releases from 1, 2, 3, ... n years back.  If you could set a
policy of handing off longterm series around the 2 year mark (and
terminating them if there is no volunteer) then that would be more
reasonable.

I see that you've accepted Willy Tarreau's offer to take over 2.6.32.y,
so if you could just formalise that before /. goes wild over the looming
end of all the above distributions, that would be nice. :-)

Ben.

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)