Re: which kernel version for etch?
On Wed, May 10, 2006 at 12:02:48PM +0200, Andreas Barth wrote:
> * Sven Luther (firstname.lastname@example.org) [060510 11:31]:
> > 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.
> We need to discuss how to update the kernel for the next stable point
> release. There is a stable release management BoF during Debconf, I'll
> try to discuss it there. Of course, anyone can come to that BoF, and I'd
> welcome anyone who helps us to resolve issues. (And this discussion
> needs to happen anyways, independend of Etch.)
I will not be at debconf, so i will not be able to participate in this
> > 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.
> I didn't claim that Sarge and Etch are the same. However, one should and
> could do the following: Which issues are problematic within Sarge? Could
> that happen in Etch again? If the answer is no, I'm happy. If not, one
> could try to fix it in time.
Seems good. I listed a few points in the past, do you want that i repeat them,
or will you find them in the archive by yourself.
> > 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.
> I'm going to discuss that with the d-i people. Hey, we could even do an
> ad-hoc BoF on kernel&d-i. :)
I doubt that it will do any good, given the d-i past positions on this, but we
will see. As said, i will not be there. I don't believe the current d-i team
has the mental flexibility enough to not see any progress on this as anything
but a lose of face, and they will strongly oppose this for that reason.
> > 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.
> I think the RMs should only address issues if the maintainers / teams /
> whoever fail to address them by themself. So for now, I'm not going to
> force anybody to something. But I definitly will discuss issues with
> different people during debconf.
Well, given that the right time to address these issues where in october, or
at least after the 2.6.14 release, that there where repeated calls for a
discussion about this, which only ended in a a bashing fest, and that we are
now in may, i think that we are already in the situation where the
corresponding teams have failed.