Re: late for party (was Re: Proposal: The DFSG do not require source code for data, including firmware)
On Thu, Aug 24, 2006 at 09:56:49PM -0700, ldoolitt@recycle.lbl.gov 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
Reply to: