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]

Date:	Tue, 16 Aug 2011 03:26:56 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Greg KH <greg@...ah.com>
Cc:	david@...g.hm, linux-kernel@...r.kernel.org,
	stable-review@...nel.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, stable@...nel.org,
	alan@...rguk.ukuu.org.uk
Subject: Re: [Stable-review] Future of the -longterm kernel releases (i.e.
 how we pick them).

On Mon, 2011-08-15 at 07:21 -0700, Greg KH wrote:
> On Mon, Aug 15, 2011 at 12:21:59AM -0700, david@...g.hm wrote:
> > rather than having a hard schedule (the first kernel released after
> > July 1 each year for example I know this is not the exact proposal),
> > I think that it would be better to pick the -longterm kernel a few
> > months after it has been released (3.4 is looking very good, the
> > normal minor driver fixes in -stable, but no fundamental regressions
> > have been reported, it's the new -longerm kernel for example)
> > 
> > doing so doesn't give the predictability that some people will want
> > in knowing that their September release will always have a fresh new
> > -longerm kernel, but I think the result would be better -longterm
> > kernels. However, to get the information about how good the kernels
> > are, I think that the -stable timeframe would need to be extended to
> > give the kernels time to settle and gather reports. I would then
> > suggest scheduling that once a year you look at the last couple
> > -stable kernels and pick one of them rather than designating the new
> > -longterm kernel ahead of time.
> 
> Yes, that's a very good idea.  I've seen problems in the past when
> distros have made a time-based decision to pick a kernel version and
> then the problems that this can cause if it happens that a subsystem
> really had issues for that release.
> 
> So yes, I'll take a look at the bug reports and how things are working
> out to pick the next -longterm.  I'll also take into consideration any
> companies/major users that are going to be using that release as well,
> so it greatly behooves people to talk to me about their plans (hint,
> hint...)
[...]

This might be a good discussion to have at Kernel Summit, if enough
distro people are going to be there.

The next stable release of Debian will have a feature-freeze in June
2012, so we need to make a choice some time before then.  However I know
that Ubuntu will need to make a decision rather earlier for the 12.04
LTS release.

Are any other distributions aiming to make long-term-supported releases
in 2012?

Also, in Debian we just added an 'rt' build of the kernel using the
PREEMPT_RT patches.  We don't want to use different upstream versions as
a basis for specific builds, so if we're going to include PREEMPT_RT in
a stable distribution release we would ideally want to see some interest
in maintaining this patchset on top of the longterm series.  (Hopefully
it's going to be significantly smaller by then, of course.)

Ben.


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