From owner-freebsd-hackers Sun Mar 12 9: 8:46 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 0471437BDF9; Sun, 12 Mar 2000 09:08:38 -0800 (PST) (envelope-from dennis@etinc.com) Received: from workstation.etinc.com (port37.netsvr1.cst.vastnet.net [207.252.73.37]) by etinc.com (8.9.3/8.9.3) with SMTP id MAA00474; Sun, 12 Mar 2000 12:07:55 -0500 (EST) Message-Id: <200003121707.MAA00474@etinc.com> X-Sender: dennis@mail.etinc.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 13 Mar 2000 00:39:47 -0500 To: Narvi , Mike Smith From: Dennis Subject: Re: Dennis' inability to fix the eepro driver Cc: hackers@FreeBSD.ORG In-Reply-To: References: <200003112227.OAA05768@mass.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 03:29 PM 3/12/00 +0200, Narvi wrote: > >On Sat, 11 Mar 2000, Mike Smith wrote: > >[snip] > >> > Why haven't you considered hiring somebody to document the parts you are >> > intersted in? Would solve at least half the problem... >> >> To be fair to Dennis, it's not the cost of paying the dropout to fix this >> driver that's at issue here. >> >> Documentation for the eepro parts is not easy to get; I only have one >> outdated hardcopy, and I get all sorts of weird stuff thrown at me. >> > >Nah. It wasn't in response to anything that dealt with the driver. Nothing >to do with eepro at all. > >It was in response to the rant about how everything was undocumented >spaghetty code so few people could make any sense of that people were >virtually dependant on those few. More communist propaganda.... :-) My *point* was simply that, not only is it difficult to make major changes to critical code without substantial documentation (all of us know that something that *looks* wrong may very will be there for an obscure reason), but when you do you lose the benefits of code improvements in the next release unless you do it again. Its not realistic. Plus, when you make a change, ANY problem with that driver, even if it has nothing to do with the change, is your problem. So, by making even a minor improvement, you take on a support responsibilty (as a commercial vendor) for code that isnt yours and may be extremely difficult to debug. dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message