Re: more current kernels for sarge in volatile?
* Sven Luther (sven.luther@wanadoo.fr) [051229 13:05]:
> On Thu, Dec 29, 2005 at 12:15:53PM +0100, Andreas Barth wrote:
> > * Sven Luther (sven.luther@wanadoo.fr) [051229 11:47]:
> > > The main problem are the too strict rules for building in volatile, which stop
> > > us from uploading the etch/sid kernels and associated packages to it.
> >
> > Actually, I think we should first consider which kernel minor version we
> > want to use (including of course the requirements on the user side like
> > udev, devfs, ...), and if we have done that, resolve any technical
> > issues with the infrastructure.
>
> Obviously, from a kernel maintainer perpespective, the one that makes more
> sense is the latest one we are working on, which will always be the more
> actively maintained one and as a consequence the one of more interest to the
> users, not to mention the fact that for the users to have any benefit, they
> need the latest kernel, not really one which is newer than the sarge one, but
> still a couple of month old.
Well, if this is going to be the other stable kernel for sarge, it will
be old and not actively maintained anyways soon enough between now and
archival of etch. So, the basic question is more: Where are we better
off with tools?
> > The basic issues are the same wherever this happens:
> > - Users should get a working upgrade path from sarge to
> > sarge-newer-kernels and from there to etch. This needs to be true for
> > the kernel and all tools included, which means we should try to limit
> > the number of changed tools as much as possible.
>
> If it is the same kernel as etch, it is obviously trivially true :)
I don't fear with the kernel, but I fear with the backported tool set.
Development is not yet frozen, and it might happen that not all
intermediate versions in etch are supported for the final version in
etch.
> > - Any security issues that happen need to be resolved - so we should
> > limit the number of versions we offer.
> Indeed, so the best is to have it be identic to either the etch or the sid
> kernel (or preferably both). They in fact don't even need to be rebuilt as far
> as i can tell, which makes offering them to users rather trivial, provided the
> support packages are there.
Well, if we want to keep the minor number in volatile, than either
kernel development has to be stalled (which is perhaps a not too good
idea), or the kernels will be different soon enough.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
Reply to: