From owner-freebsd-current Wed Sep 4 22:32:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA22842 for current-outgoing; Wed, 4 Sep 1996 22:32:07 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA22798 for ; Wed, 4 Sep 1996 22:32:00 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id PAA09729; Thu, 5 Sep 1996 15:01:20 +0930 From: Michael Smith Message-Id: <199609050531.PAA09729@genesis.atrad.adelaide.edu.au> Subject: Re: Latest Current build failure To: rkw@dataplex.net (Richard Wackerbarth) Date: Thu, 5 Sep 1996 15:01:20 +0930 (CST) Cc: dg@Root.COM, current@FreeBSD.org In-Reply-To: from "Richard Wackerbarth" at Sep 4, 96 10:04:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Richard Wackerbarth stands accused of saying: > > This new scheme will buy absolutely nothing but additional headaches if you > attempt to run it in parallel with the existing chaos. Even if it were > implemented, it would take additional effort to build the critical user > mass that makes it worthwhile. You would also have the "documentation" > problem of explaining "how this is different from that". As I see it, this is the critical difference of opinion around which all contention revolves. You put your point succinctly (for once 8); let me try to put the opposing side : The new scheme will have implementation problems, which simply due to the number of people involved will be _astronomical_. Running the two in parallel will allow the affected parties to chose their own time and means of cutover, taking the strain off considerably, and leaving a convenient fallback should the new system hiccup while it is being sorted out. You _cannot_ expect instant results with a change such as you are proposing. The documentation and "critical mass" issues are costs that would simply have to be borne - the alternatives are absolutely impalatable, and it is in refusing to address this fact that you are falling foul of semi-popular opinion. > Since you, collectively, are unwilling to accept anything that an outsider > does unless it is a completely implemented, tested and documented package, > you will never, IMHO, solve the fundamental structural problems of your > approach nor realize the values that can be reached in incremental steps. Here you are showing signs of hysteria. That's Bad. 8( A simple demonstration along the lines of "here, try this", is what's needed. So far you've insisted on acceptance before the fact, which is something that's patently unrealistic. -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[