Re: which kernel version for etch?
On Wed, May 10, 2006 at 11:16:31AM +0200, Andreas Barth wrote:
> * Frederik Schueler (fs@debian.org) [060509 23:47]:
> > Second, if we go this path and do an Etch release with 2.6.16.x,
> > I would like to NOT stick forever with that very version we will have in
> > testing at the day the freeze happens, but keep updating the kernel
> > images and the installer for every point release to a reasonably newer
> > 2.6.16.x upstream release.
>
> We need to discuss how to do it sanely for the installer; I'll discuss
> that with Frans anyways during debconf for Sarge, and what we learn from
> that for Etch. Otherwise, this is ok from the stable release management
> point of view.
Andreas,
Well, there are a few points to see here :
1) Frans is hardly competent enough to give advice for this. He is biased by
his personal feud over this with me, and i believe has not a good enough
oversight of the problems involved to give a good technical advice. This is my
opinion, though, so feel free to ignore it.
2) Any discussion about this issue done during the sarge time can be thrown
in the trashcan. Remember the mess that was the kernel packages in sarge,
and compare it to the current situation.
3) We are able to do kernel uploads, rebuilt for all arches in a matter of
days (same day for most major arches usually). The upload of 2.6.14-1 and
later first time upgrades has shown that.
4) Back in the sarge time, a full d-i rebuild meant over a month of work. We
have solved all the issues we had with this on the kernel side, and the
delay is now caused by a lack of organisation on the d-i side, and their
refusal to address the issue.
5) We shipped sarge d-i with a known remote security hole, let's try to
avoid such issues if possible. We still have time to make it work.
If we solve the issue of the out-of-tree modules, and get the d-i kernel
.udebs situation in grip, then there is no reason at all we should be able to
do even abi-breaking upgrades in a matter of days. This means some change in
the infrastructure of netbooting and businesscard .udebs, but if there is a
will to solve this as it should, we could do this before the etch freeze.
I believe it is the RMs place to have enough vision to find the best technical
solution, and to make sure they happen, even if a few try to block it because
they are afraid of change.
So keep in mind of what would be best for etch once released, and let's try to
make it happen.
(BTW, the mediation attempt between me and the d-i team failed, i am
disapointed on how the DPL handled this, and his lack of impartiality, so any
d-i side of the thing will not be handled by me, unless it is forked and
maintained in a more free way).
Friendly,
Sven Luther
Reply to: