On Wed, May 10, 2006 at 12:02:48PM +0200, Andreas Barth wrote: > * Sven Luther ([EMAIL PROTECTED]) [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]