Re: which kernel version for etch?
On Tue, 16 May 2006, dann frazier wrote:
<snipp stable update - going to separete thread>
> However, to meet the etch release schedule, we need to begin freezing
> the kernel relatively soon. I am not sure what those dates are
> though; hopefully this will become more clear after the etch release
> discussion at debconf on Thursday (iirc).
indeed the release schedule impose that.
but releasing with an old frozen kernel has not the same advantage
as the old glibc which still supports the 2.4 kernel line.
so if in the freeze time we get something much better it makes sense
to push that release.
> The bit I find interesting about 2.6.16 is that Adrian Bunk has
> proposed maintaining a 2.6.16 branch where new *features* are
> permitted, and it sounds more inline with how 2.4 was maintained once
> 2.5 had forked. If this happens, it *should* provide a more
> controlled tree than Linus' from which we can pull in updated features
> like atapi, acpi, etc, and continue to sync them into our testing
> kernel until the freeze. If we could have trivially cherry-picked
> features from 2.6.10 and backported to 2.6.8 before sarge, I think we
> would have; but the number of changesets between the two was so
> immense that we only really considered moving completely to 2.6.10.
2.6.16 has seen major distro stabilisation as seen of the hight nr.
of stable kernel releases. i thus think that it is a good canditate per
se. although i would keep a window open for 2.6.18 if we get it ready
during the freeze and it works better. 2.6.17 is said to be used by
no major distro [1]. for sarge we could have pusshed 2.6.10 if we had
worked earlier on that release. although it was not so easy to rebase
on those times.
i've not seen any bit of that tree yet and there is already a lot
of new features to backport. until that "stable" tree appears talks
are pretty much speculations.
regards
--
maks
[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=114780190710723&w=2
Reply to: