Kernel Bug Migration
Ben Collins
ben.collins at canonical.com
Tue Jun 17 14:07:37 UTC 2008
On Tue, 2008-06-17 at 10:55 +0200, Krzysztof Lichota wrote:
> 2008/6/11 Tim Gardner <tim.gardner at canonical.com>:
> > Leann Ogasawara wrote:
> >> For 2.6.15 bugs I proposed a slightly different process just because it
> >> was an LTS release. But I'd be fine with using the same procedure above
> >> that I'd use with the other non-LTS kernels.
> >>
> >
> > I can't think of a good reason not to use the same algorithm for Dapper.
> > My support focus is primarily on server and CVE issues. Desktop users
> > suffering from bugs are just going to have to upgrade to a recent
> > release where their issue is more likely to get addressed.
>
> Seems like the opposite of the whole LTS idea. Fix-by-upgrade is not a
> solution. Newer release could introduce other bugs and then what?
> Upgrade to even newer version? Not to mention that LTS releases are
> rare, so there might be no newer LTS version to upgrade to.
>
> IMO bugs should be fixed in LTS kernels and/or newer kernels should be
> backported to LTS releases.
For LTS releases, we only guarantee that we wont regress the kernel, and
that we will keep it up-to-date with security fixes. Fixing known bugs
is on a best-effort basis and is not guaranteed. So this isn't anything
new.
More information about the kernel-team
mailing list