From owner-freebsd-net Sat Jul 28 13:13: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id 84CDE37B405; Sat, 28 Jul 2001 13:12:55 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.247.137.129.Dial1.SanJose1.Level3.net [209.247.137.129]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id NAA16424; Sat, 28 Jul 2001 13:12:52 -0700 (PDT) Message-ID: <3B631CEB.944A9750@mindspring.com> Date: Sat, 28 Jul 2001 13:13:31 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nik Clayton Cc: Julian Elischer , "Eugene L. Vorokov" , Soren Kristensen , freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: Why two cards on the same segment... References: <200107260837.f6Q8b9K00767@bugz.infotecs.ru> <3B5FDD32.7758EB35@elischer.org> <3B6055C8.C0B5554D@mindspring.com> <20010727013402.G17126@canyon.nothing-going-on.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Nik Clayton wrote: [ ... ] > > So, the major reasons for two cards on one segment: to work around > > bugs in FreeBSD's networking code. > > Have you submitted these bugs using send-pr(8)? No. The last three times I attempted to use send-pr(8), it bitched about my email address. It seems to me that it's pretty useless. It also seems to me that, even if it worked, driving yourself by a bugs database instead of a product roadmap is bound to get you incremental improvements only. There are a lot of organizations, some of which I have participated in, which lose enhancement requests into their bugs database; from that perspective, there is a need for a seperate "importance" factor, aprat from the traditional "severity" factor; even then, there is a tendency to bury your engineers in a bunch of "previous product++" changes, instead of tackling real problems. In the abosolute worst case, I know that there are Linux and NetBSD people monitoring these lists, and they will implement the code, even if FreeBSD doesn't, and then FreeBSD will implement it to "catch up". The NetBSD KSE code is just the latest example of this. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message