lkml.org 
[lkml]   [2011]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2011-08-15 09:25    [from the cache]
©2003-2011 Jasper Spaans