On Tue, Oct 21, 2008 at 02:52:42PM +0000, Robert Millan wrote:
> Traditionally, we have assumed good will, and specially cooperation from
> the release team; DFSG violations were considered "Release Critical" bugs
> and therefore every one of them would have to be fixed before release.
There are two kind of Release Critical bugs. The ones that affect the
usability of a software (independently of any religious issues wrt its
licenses and the blobs it contains), and the one due to incompatibility
with the Debian Policy or the DFSG or similar (the religious issues).
The bugs from the former kind are seldomly tagged lenny-ignore (if it's
appropriate, they are downgraded, or fixed, or the package is removed).
The latter kind, if it's practical, leads to a move to non-free or
contrib, or leads to removals.
Though, when this software is central to all Debian (as the kernel is,
or the glibc for the sunrpc issue, or mesa for the GLX code, or ...),
then as it's a long and slow work to either prune the firmware, or deal
with the copyright holders to relicense (and mesa has made it, proof
that it's possible, but it needed like 2 or 3 releases of Debian to do
so !), the Release team acknowledge that progress has been made, and
tags the bugs $suite-ignore.
> At this time (and I believe, in part due to historical reasons), the release
> team has made it clear that it is not their responsibility to enforce the SC.
Why on earth should it be the Release Team ? It's everyone's. The
Release Team tries to ... wait for it... release. I explained what is my
(and I believe other RElease Team members) rationale wrt how "fixing" or
"ignoring" bugs above.
> There are four options, which reflect two orthogonal binary choices:
>
> - Whether to make this resolution become part of the SC or not.
>
> - Whether to provide exceptions that would allow Lenny to release sooner.
Your proposal misses the point. DFSG wrt firmwares is a hard issue, and
your black-and-white vision of it isn't adapted. The 60-days or move the
package to non-free would move the glibc and portmap as is to non-free.
Good luck with that. (Just to show how impractical it is).
No I'd rather see something sensible about the firmware issues sorted
out. I'd like to re-state long known arguments:
* firmwares are part of the hardware, even your CPU has microcode. You
don't have the source code that generated the circuits of that
hardware, having the source-code of the firmware will hardly help. I
know that "firmwares are in Debian my hardware is not" but unlike
flash or java, there is a bootstrap issues where we (I think) should
think more of our users than you do. Not all platforms can deal with
a secondary media with all the firmwares in it. This means that
you'll go backwards in term of d-i features, and that implies a big
regression.
* Even when you have the firmware "source", without the toolchain used
to generate them you won't go anywhere, and it's IMHO the most
significant point to be made. Freeness of software is about being
able to fix bugs and modify programs. Here you could modify source,
big deal, you won't be able to *build* the damn firmware. ever. So
what's the point ?
To me the firmware issues boils down to that:
1. is the blob redistributable and compatible with the software license
yes or no. If no, that's an issue that needs addressing. If yes,
then there should be no problem.
2. is the firmware *only* running in the hardware (IOW are we sure
there is absolutely no code that would be mmaped and executed inside
the host). yes or no. If yes, then it's good. else we want the
source of it, because *this* we can fix and modify, and we have a
toolchain for that.
Comparing documentation only distributed under PDF and binary firmwares
of 512 octets and pretend it's the same issue is a red herring, and a
total lack of nuance.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgp5ddkRVcjHs.pgp
Description: PGP signature