Re: Rethinking stable updates policy
On Sat, Aug 26, 2006 at 02:13:33AM -0500, John Goerzen wrote:
> On Sat, Aug 26, 2006 at 08:43:53AM +0200, Martin Schulze wrote:
> > John Goerzen wrote:
> > > Examples of things that should happen in stable, but haven't been
> > > happening reliably:
> > >
> > > * Kernel updates with more broad hardware support
> >
> > This requires new kernel packages, new utilities and a new installer.
> > It a hell of an effort to get this done. Just look at what it takes
> > to update these in stable with "only" security updates.
>
> New kernel packages, and a rebuilt install image, yes. New utilities?
> Which utilities?
>
> The only one I'm aware of that breaks with newer kernels is udev, and
> hasn't that been fixed for awhile now?
>
> I've never had a problem taking a stable box and putting a nice shiny
> new kernel on it. Which utilities have to be updated here?
>
> I'm not talking about something like 2.4 to 2.6, just point releases
> within 2.6.
Well, the etch preparation time saw the switch to 2.6, the devfs removal and
the corresponding ramdisk generator troubles, as well as assorted udev
troubles.
The real problem, is that for seamless kernel upgrades, a lot of
infrastructure is needed, and this has been part of my plan (or private agenda
like Frans accused me of, altough there is nothing private about it, since i
claimed it high and strong since over a year now, and it is done not to
further my own benefit, but for the best of debian, the ease of the stable
security team and stable d-i upgrades, and situation likes this.
Anyway, the plan i was proposing since april 2005, shortly before the etch
release, called for an unified kernel package (which we attained in a
successfull way, culminating with the 2.6.14 release and its same-day upload),
as well as other yet to be implemented or currently under implementation
parts. It had :
- a single kernel source package, building all the .debs for all arches, as
well as all the .udebs for d-i.
- an infrastructure for out of tree modules, either incorporating them in
the same main kernel package like ubuntu has done, or a single out-of-tree
package like is under way, or a set of individual such out of tree
packages, but identified ones, and all using the same infrastructure.
It was trying to push for this one, which would make upgrading kernels on
kernel abi changes for security or upgrade issues seamless, but faced the very
strong and agressive oposition of the d-i team, who is now in a situation
where any changes in this respect cannot be accepted by them, for fear of
losing face and having to admit that i was right, so we are thus hosed in the
near future.
This plan needs to be complemented by cooperation with the other kernel
related tools, like udev, module-init-tools and such.
With all this in place, we could do kernel and d-i upgrades in a matter of
days, and it only would need tests for regressions in the kernel code itself,
or in the interface of those helper tools, but given the importance of those
kernels upgrades (a quick test, who really runs sarge kernels on sarge, and
not some self-built or backported ones ?), it would be fairly easy to find a
big enough tester set to validate those for later upgrades.
Friendly,
Sven Luther
Reply to: