Re: Proposal - Defer discussion about SC and firmware until after the Etchrelease

[ldoolitt@recycle.lbl.gov]

Thank you, Frans, for your thoughtful and informative post.
I have a couple of questions/comments.

> implementation of a solution for firmware/non-free drivers in d-i has
> been discussed but consensus was that there was not much point in
> working on it while there was no separation in the kernel;

This is half-true.  

It is true that many high-profile drivers in the upstream kernel _still_
have their firmware mingled with the (often GPL'd) driver, and their
developers show resistance to treating that as a bug.

But it is also true that the upstream kernel has used the request_firmware()
mechanism (for a subset of its drivers) for quite a while.  As a random
data point, the March 2, 2005 release of linux-2.6.11 included about 20
drivers that used that mechanism to load their firmware.  So if the
Debian project (kernel and d-i together) had interest in supporting the
separation, there were ample test-cases available.

> (a) The inclusion in main of sourceless firmware and support in
> Debian Installer is not a release blocker for the release of Etch.
>
> (b) For the release of Etch, the Release Managers are given discretion
> to waive RC issues in other cases where the letter of the Social
> Contract is currently not being met, provided there is no regression
> relative to the Sarge release and [chop]

The only thing that pains me here is the contrast that implies that
sourceless-firmware regressions are OK.  Yes, I know there are good
reasons for that.  And it sounds like the only practical option (other
than to delay etch) is to drop support (in whole or in part) for 
Broadcom NX2, Sun Cassini(+), Intel PRO/100 (although some of those
chips are also supported by the unaffected eepro100 driver), Starfire,
Tigon3, QL1040, TI2410, TI5052, and (maybe) five more members of the
QL2xxx family.  This is either a non-problem or a deal-breaker,
depending on whether or not you own such hardware.  ;-)

> unless both Joey Hess and I, after careful review of a finished and
> tested proposed solution, decide that 1) it provides an acceptable
> solution for all installation methods and architectures, 2) it poses
> no risk of regressions or delays in the run-up to the release."

Do I interpret this correctly, that the existing firmware-nonfree
package will only be useful post-etch?

     - Larry