Re: irc meeting regarding kernel status d-i RC3
On Tue, Feb 01, 2005 at 09:50:29PM -0500, Joey Hess wrote:
> Horms wrote:
> > By my calculations that is 3am on Saturday morning in Japan,
> > I am not sure I will be in an appropriate state to be having meetings
> > at that time.
>
> It's noon here, I may be awake for the meeting, if so I will attend. No
> promises however.
>
> > My 2c worth here is that frankly 2.6 is highly problematic in terms
> > of trying to stabalise. We clearly have a number of bugs in 2.6.8 that
> > are unlikely to ever be resolved - e.g. ACPI. And in many cases
> > 2.6.10 is in much better shape. But there is still more or less a flood
> > of fixes going in to 2.6 upstream, for instance there are any number
> > of fixes to the network since 2.6.10 (though admitedly probably not
> > as many as between 2.6.9 and 2.6.10).
> >
> > So I am definately of the oppinion that we would be trading old bugs for
> > new. But that may not be such a bad thing. For one, we know some of the
> > bugs in 2.6.8 that hurt us (xfs, ACPI, ...) are in a better state in
> > 2.6.10 - I am personally running 2.6.10 on systems that I use 2.6 on,
> > and so are other people I work with, and its because 2.6.8 didn't work
> > for one reason or another. For another it would be an excellent chance
> > reduce from 3 (2.6.8,9,10) to one, the number of 2.6 kernels on d.o, and
> > thus focus our efforts on one 2.6. In fact, if I was asked for one
> > recommendation that would be it.
>
> If the kernel team has been unable to concentrate on 2.6.8 now that
> 2.6.9 and .10 have come out, why do you think you'll be able to
> concentrate on 2.6.10 once .11 and .12 come out?
Point taken. However I think that the reall point is,
we decided to go with 2.6.8 a while back. But that has
turned out to have some significant problems. Is it worth
jumping onto another boat at this point? To be honest, I am
in the no camp, but I think that the real answer likes in
looking at what exactly is wrong with 2.6.8 that we know
is right in 2.6.10 and vice versa. I.e this discussion.
> Since changing the kernel version used by the installer will delay the
> sarge release by at least a couple of months, the existence of yet more
> kernel versions seems likely.
>
> Why can't the kernel team backport fixes to 2.6.8?
Some of the changes are just too extensive to make backporting sane.
The question is, are these extensive changes relevant to us.
> > The 2.6 development model places the onus of stabalisation much more
> > firmly on the distributions. I am of the mind that Debian would have
> > more chance in getting things stabalised if we can focus on one 2.6
> > kernel.
>
> Yes and we should have been focusing on one kernel since the decision
> was made several months ago to stop looking at newer kernel versions for
> sarge. If you go ahead and change the kernel now, after we've just
> finished[1] dealing with the fallout of updating both gnome and kde to
> new upstream versions in sarge, and when i386 is no longer installable
> at all because of a new parted upstream that was just shoved in (w/o
> consulting me :-( ), then we may as well rename sarge to "etch" and
> "rc2" to "sarge release" and be done with it.
The real problem here, as far as I see it, is that we have 2.6.8, but
in order to allow people to play with newer code and to see what
has been solved upstream we put 2.6.9 and subseqhently 2.6.10 in
the tree. Not my choice incidently, and in my oppinion this
has taken some effort away from 2.6.8.
--
Horms
Reply to: