Frederik Schueler wrote: > On Sun, Sep 24, 2006 at 11:25:15AM -0400, Nathanael Nerode wrote: >> If the firmware-loading tg3 driver is present in the next kernel package >> version, I will believe that the kernel team is acting in good faith to >> try to satisfy the Social Contract. > > According to the kernel-team patch policy, this patch needs to be either > a backport from a newer version, or a patch submitted and accepted > upstream.
I'm afraid this is an unacceptable policy. According to this policy, an intransigent upstream maintainer can and will hold Debian hostage by forcing Debian to continue distributing unlicensed material in violation of law, or by forcing Debian to violate its Social Contract. I expect this to happen, though of course I hope it won't. Change this policy. You really must make two exceptions: (1) Removal of material which Debian cannot legally distribute, if upstream insists on keeping it. (2) Removal of material which does not satisfy the DFSG, if upstream insists on keeping it. If you want to wait to remove material until it's clear that upstream is intransigent, that's one thing, but if it becomes clear that upstream is intransigent, that's another thing. > Where can I find the current version of your patch? ldoolitt updated it to the current kernel: he's sending me a copy. If he doesn't send you a copy, I will. Would you like it in a new bug report, attached to the giant monolithic linux-2.6 license and freeness bug, or what? :-) (This is one reason I supported one bug per driver: it allows tracking the individual problems separately in a straightforward way.) I'm thinking of adding slightly more verbose logging to help testers identify which board they're dealing with. > AFAIK it was > rejected upstream because some functionality was broken, This is, essentially, wrong. I have explained the reasons why it was rejected upstream elsewhere. I will submit it again, of course, but I expect hostility to any firmware loading patch for tg3, and I will be pleasantly surprised if I get a fair hearing. One piece of "broken functionality" is loading firmware before the root partition is mounted -- the lack of this breaks netbooting on the boards which need the firmware. However, I can't do anything about this: it requires running udev in the initramfs. This problem is not specific to this driver. A second piece of "broken functionality" is the functionality provided by the firmware: if the firmware isn't there and isn't loaded, the functionality isn't there. Duh. I also can't do anything about this. Apart from those, the patch has no known functional regression (there was one bug fixed by Herbert Xu related to machines with multiple tg3 cards), and I wish people would stop slandering my work. > this regression > needs be fixed and the patch resubmitted in order for us to consider an > inclusion. > > Then, firmware-loading support in d-i is still missing, this issue > should be be fixed too before we consider the patch. Firmware loading support patches are being refused in d-i until after etch is released. Therefore, this amounts to a "We will not accept any firmware loading patches until after we release etch" policy. Good to know. I can still queue them up for you to commit afterwards, though. > I have a board with tg3, so I can perform the needed testing. Maybe you can, maybe you can't. The firmware is only used on certain boards: you are quite likely to have one of the needs-no-firmware boards. Thanks for the offer; any testing is good, even on the needs-no-firmware boards. I'll try to get you a slightly revised patch relative to ldoolitt's version: I want to add a little extra logging. > Best regards > Frederik Schueler Thanks for your time. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
