From owner-cvs-sys Mon Apr 28 03:53:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA06835 for cvs-sys-outgoing; Mon, 28 Apr 1997 03:53:50 -0700 (PDT) Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA06809; Mon, 28 Apr 1997 03:53:14 -0700 (PDT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id LAA02432; Mon, 28 Apr 1997 11:50:24 +0100 (BST) Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 28 Apr 1997 11:53:43 +0100 Received: from tees.elsevier.co.uk (tees.elsevier.co.uk [193.131.197.60]) by cadair.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id LAA27872; Mon, 28 Apr 1997 11:53:34 +0100 (BST) Received: (from dpr@localhost) by tees.elsevier.co.uk (8.8.5/8.8.5) id LAA05960; Mon, 28 Apr 1997 11:53:33 +0100 (BST) To: "Jordan K. Hubbard" Cc: Garrett Wollman , CVS-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-sys@FreeBSD.org Reply-to: paul@originat.demon.co.uk Subject: Re: cvs commit: src/sys/net if.c etc. References: <4753.862176226@time.cdrom.com> From: Paul Richards Date: 28 Apr 1997 11:53:31 +0100 In-Reply-To: "Jordan K. Hubbard"'s message of Sun, 27 Apr 1997 14:23:46 -0700 Message-ID: <57g1wbxvtg.fsf@tees.elsevier.co.uk> Lines: 33 X-Mailer: Gnus v5.4.37/Emacs 19.30 Sender: owner-cvs-sys@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk "Jordan K. Hubbard" writes: > experience in networking and a knowledge of exactly what sorts of > issues Tony is going to need to deal with to "catch up" to 3.0 > actually CALL Tony first? That would make major points, and during If it were just Tony then that would be a nice idea but really there needs to be a better way of dealing with all vendors. I agree that we need to support vendors but it would be a grave error to shift the emphasis towards backward compatibility rather than forward momentum. I think the only fair way of dealing with this is to set up a vendor registration process, where vendors sign up with the project so that we know they base products on release X and then all vendors can be notified in a timely manner when we expect a future release to break compatibility with older releases, providing enough documentation to allow them to migrate. At the end of the day it's then up to them whether they want to roll their products forward or not. From our point of view this requires more effort in that documentation (in some form) has to accompany major changes like this but I think that's something that's sadly neglected anyway. In many regards this project is run in a very professional manner but one area where it really looks like a bunch of enthusiasts is in its lack of documentation. Design documentation that is, the user documentation is something that has been considered and worked on. -- Dr Paul Richards. [p.richards@elsevier.co.uk] Originative Solutions Ltd. [paul@originat.demon.co.uk] Phone: 0370 462071 (Mobile), +44 (0)1865 843155 (Elsevier)