On Thu, Aug 24, 2006 at 09:56:49PM -0700, [EMAIL PROTECTED] wrote: > Sven Luther wrote in > http://lists.debian.org/debian-vote/2006/08/msg00125.html > > I would indeed vote for a solution including a non-free hardware, > > or even better an additional CD, which contained a non-free > > version of d-i (which need to include certain non-free firmwares > > and drivers in the images), and all the additional non-free > > firmware stuff. > > This way, we could add a list of pci ids needding non-fre > > hardware, and do a check pretty early in the installer, and > > if those non-free hardware is found, inform the user about it, > > and use the non-free installer CD instead, and all > > the rest would be taken care for him. > > Nice idea, Sven. Do you really think that can work reliably > for etch, in December?
No, it is already too late. The time to work on this was quickly after the sarge release last fall, but upstream was not ready, the kernel team was hard working on things like the common package, and the devfs removal / ramdisk generator issues, and in general to bringing a more timely release schedule in action. Other teams clearly dismissed the issue and are now also blocking point. As thus, the most reasonable way, would be to delay the issue until etch+1, which gives us time to work on it in tranquility, be able to make more adventursome choices and experiments, without the fear of breakage that comes at a moment where major component affected (kernel, d-i) are already frozen. > While Steve's proposal item (4) is just plain false, I can > certainly see the argument to continue to make a firmware > exception for etch. I would support such a plan only if it > was explicitly etch-only, and linux-2.6 only, and there was > a commitment to rip out superficially illegal GPL/s-f-c files > the day after etch releases. Well, not the day after the etch release, but shortly thereafter. I do believe that there is a certain rythm to a release schedule. At first after a release is a time of rest, where the pression of the release is evacuated, and it is a time for thought and reflexion over what went badly, and what could be improved. Then is a time for more adventursome changes, new implementations, and so on, then once the choices are implemented, they are validated through a time of testing, and then we enter in the pre-release fine-tuning phase culminating with the release. We are now in that last phase, and it is too late for a solution to the non-free firmware issue for etch, and our best guess would be to get it out of the way quickly, and be able to concentrate on it post etch. The problem also was that a certain amount of developers had trouble with the above rythm, and kind of believed they where already in the no-major-change fine-tuning period immediately after sarge, most prominent among them the d-i team, probably due to lack of man power after the post-sarge defection. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]