lkml.org 
[lkml]   [2000]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.3.51 tulip broken
With regards to your message at 11:33 AM 3/18/00 -0500, Jeff Garzik. Where 
you stated:
>Donald Becker wrote:
> > A quick search of the two very active Tulip mailing lists reveals that you
> > have contributed nothing until this year. Apparently you were not even a
> > subscriber until then, and know nothing about the very open way development
> > has been done. Yet you willing throw around pejorative phrases like
> > "cathedral style" -- a hot button in this community.
>
>I see only the end results, and especially the cathedral style of
>development as applied to your pci-netif changes.
>
>Let's look at your FTP site.
>
>Stable tulip.c -- last updated Dec 28, 1999.
>Stable eepro100.c -- Last updated Aug, 1999.
>All other stable drivers are older than this.
>
>Test 3c59x.c -- last updated Dec 15, 1999.
>Test eepro100.c -- last updated Sep 1999.
>test winbond -- last updated Sep 1999.
>test via-rhine -- last updated Aug 1999.
>All other test drivers are older than this.
>
>(pci-netif stuff)
>2.3 rtl8139.c -- last updated Oct 1999.
>2.3 epic100.c -- last updated Oct 1999.
>All other 2.3 drivers last updated in Sep 1999.
>
>In short, none of your drivers appear up to date, especially with
>respect to the bugs I see being reported on the eepro100, rtl8139, and
>other lists. Stable tulip seems to be the one driver updated recently
>-- and that was over three months ago.
Donald, and others involved in tulip driver development:
I am NOT a developer. I am a person running a company using tulip type and
other network cards in our products.
As such I can not comment on design philosophies.
I CAN make the following statements:

1) When seeking new updates for drivers I keep seeing references to a very
old .89H version, and then have to seek long and hard to find the patches
and info to make various cards "work"

2) There are no obvious locations to obtain the updates and patches needed.

As a result ethernet device support is chronically one of the biggest
support ticket items we run into on Linux machines.

Whatever the cause may be (and I am not the one to judge), it appears that
_something_ needs to be somewhat differently. It _would_ be nice if someone
took on the task of ensuring these are more tightly integrated with kernel
development and distribution. It is a pain to always have to update what
comes with new distributions. I am not speaking of development kernels,
just the "even numbered" release version.

What is happening now is problematic.

Whether the reasons Jeff and others state is "it", or something entirely
different, I simply am not willing to guess. Taking "sides" is unlikely to
be helpful.

However, I also don't want to see Donalds' efforts go unrecognized.

We _do_ need to move forward to finding a more "streamlined" model for this
process.

Just $.02 worth from somebody on the "deployment" side of things..


Best regards,

Maurice W. Hilarius Telephone: 01-780-456-9771
Hard Data Ltd. FAX: 01-780-456-9772
11060 - 166 Avenue mailto:maurice@harddata.com
Edmonton, AB, Canada http://www.harddata.com/
T5X 1Y3



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.103 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site