Re: Preparing linux-2.6 2.6.18-1
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 <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: