[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: which kernel version for etch?



On Wed, May 10, 2006 at 12:02:48PM +0200, Andreas Barth wrote:
> * Sven Luther (sven.luther@wanadoo.fr) [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
discussion.

> >   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.

Friendly,

Sven Luther



Reply to: