Re: pci-skeleton duplex check

[Jeff Garzik <jgarzik@pobox.com>]

Donald Becker wrote:
> On Thu, 12 Dec 2002, Jeff Garzik wrote:
> 
>>Donald Becker wrote:
>>
>>>[[ I don't know why I bother. The people that now control what goes into
>>>the kernel would rather put in random patches from other people than
>>>accept a correct fix from me. ]]
>>
>>I'm very interested in applying fixes from you!  I am publicly begging 
>>you to do so, and even CC'ing lkml on my request.
> 
> 
> This is very disingenuous statement.


Oh come on, it's far less disingenuous than what you said:

	[[ I don't know why I bother. The people that now control what
	   goes into the kernel would rather put in random patches from
	   other people than accept a correct fix from me. ]]

I'm sure you'll continue making snide comments on every mailing list you 
maintain, but the fact remains:

I would much rather accept a fix from you.

That hasn't changed in the past year.  or two.  or any amount of time. 
Your input is very valuable, and I typically save quite a few of your 
emails.


> The drivers in the kernel are now heavily modified and have significantly
> diverged from my version.  Sure, you are fine with having someone else
> do the difficult and unrewarding debugging and maintainence work, while
> you work on just the latest cool hardware, change the interfaces and are
> concerned only with the current kernel version.

While I disagree with this assessment, I think we can safely draw the 
conclusion that the problem is _not_ people ignoring your patches, or 
preferring other patches over yours.


> I've been actively developing Linux drivers for over a decade, and run
> about two dozen mailing lists for specific drivers.  I write diagnostic
> routines for every released driver.  I thoroughly test and frequently
> update the driver set I maintain.  And since about 2000, my patches were
> ignored while the first notice I've have gotten to changes in my drivers
> is the bug reports.  And the response: "submit a patch to fix those
> newly introduced bugs".  I've even had patches ignore in favor of people
> that wrote "I don't have the NIC, but here is a change".

I don't recall _ever_ getting a patch from you or seeing one posted on 
lkml or netdev.  How can you be ignored if you're not sending patches?


> A good example is the tulip driver.  You repeatedly restructured my
> driver in the kernel, splitting into different files.  It was still 90+%
> my code, but the changes made it impossible to track the modification
> history.  The kernel driver was long-broken with 21143-SYM cards, but no
> one took the responsibility for fixing it.

s/was/is/
I take responsibility for fixing it, I just haven't fixed it yet :)


> It's easy to make the first few patches, when you don't have to deal
> with reversion testing, many different models, and have an unlimited
> sandbox where it doesn't matter if a specific release works or not.  But
> it takes a huge of work to keep a stable, tracable driver development
> process that works with many different kernel versions and hardware
> environments.


We're slowly getting there, in terms of regression and stress testing.

Since you don't send patches anymore for a long time, I was really the 
only one [stupid enough?] to stand up and even bother to help collecting 
and reviewing net driver changes.

I would love to integrate your drivers directly, but they don't come 
anywhere close to using current kernel APIs.  The biggie of biggies is 
not using the pci_driver API.  So, given that we cannot directly merge 
your drivers, and you don't send patches to kernel developers, what is 
the next best alternative?  (a) let kernel net drivers bitrot, or (b) 
maintain them as best we can without Don Becker patches?  I say that "b" 
is far better than "a" for Linux users.

	Jeff