Message-ID: <alpine.DEB.2.02.1108150007100.24266@asgard.lang.hm>
Date:	Mon, 15 Aug 2011 00:21:59 -0700 (PDT)
From:	david@...g.hm
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
Subject: Re: Future of the -longterm kernel releases (i.e. how we pick
 them).

On Sun, 14 Aug 2011, Greg KH wrote:

> 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.
> - -stable kernels keep the same schedule that they have been (dropping
>  the last one after a new release happens.)  These releases are best
>  for products that require new hardware updates (desktop distros,
>  community distros, fast-moving embedded distros (like Yocto)).
> - the normal -stable rules apply to these -longterm kernels as described
>  in Documentation/stable_kernel_rules.txt
>
> 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 am one of the people who runs kernel.org kernels on my companies 
systems, and so I think I am well within the target of this proposal.

First off, let me say 'thank you' for your work here, now on to the ugly 
details :-)

There is definantly a need for a kernel that's maintained longer than the 
current -stable series is, there just isn't enough time to get comfortable 
with a new kernel before the -stable stops being maintained. What I end up 
doing is watching the vendor lists for alerts on things that relate to my 
configurations, and when I see them, work to jump to the latest kernel. 
this works, but not especially well.

a more regular -longterm kernel is appealing, but as I have been doing 
this since the kernel 1.3 days, I have seen a lot of kernels that ended up 
with just not being that good in subtle ways, and I'm not sure that just 
trying to backport smallish patches can really solve the problem.

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.

I hope my midnight rambling makes some sort of sense :-)

David Lang
--
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