Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
I apologize for responding to Marco's post; in retrospect he was clearly
trolling and I should not have responded to him.
The point of my initial message was not to argue: it was that the etch
timeline is unrealistic, because I see no progress on removing the
substantial number of sourceless binaries from the Linux kernel source
package, and it's *after* the kernel was supposed to have frozen!
Is there a plan for dealing with this fast enough to avoid delaying the
release of etch? If so, please post it.
If not, I suggest the following process improvements:
For each driver containing a sourceless binary, someone (probably me) will
file a single bug against the source package linux-2.6. Currently there is
a single bug (242866/243022) covering multiple issues, against 'kernel',
which is a pseudo-package. Looking at the list of antique bugs
against 'kernel', I don't think anyone is reading them. Also, with the
planned removal of
pre-2.6 kernel packages, a bug against linux-2.6 seems sufficient to cover
everything.
Why one bug per driver? Because each driver's bug is slightly different
and I expect each to be fixed in a slightly different way. Some bugs are
distributability issues, while some are clearly distributable and simply
non-free. Some may be fixed by a new upstream version. Some may be fixed
by implementing firmware loading and a non-free firmware package; some may
be fixed by moving the driver to an out-of-tree kernel module; others may
be fixed by removing the driver entirely; others (where the firmware is
unimportant) may be fixed by removing the firmware and the support for
whatever feature it enables. In the case of the DRM modules, the result
may depend on the implementation of features in X, and bugs may block on
that. The point is that each case is going to be different. The progress
on the different drivers is already different.
This should make tracking the issues significantly clearer: specifically it
will make it clear exactly what needs to be done to fix this. It would
also make it look a bit less like an infinite tentacled monster, perhaps
making it easier for people to bite off one bug at a time. (Certainly I
get confused posting fixes for different drivers to the same bug.) We
would then convert 242866 to a meta-bug blocking on each individual bug.
How does that sound?
http://wiki.debian.org/KernelFirmwareLicensing is grossly out-of-date, but I
will integrate the relevant information from that in the process.
Alternative option: the Wiki page could be revived and used to coordinate
the process. Unfortunately it's quite out-of-date, and it's unwieldly. I
prefer the BTS option because it's more permanent, harder to ignore, and
better at holding patches and whatnot.
--
Nathanael Nerode <neroden@fastmail.fm>
Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...
Reply to: