From owner-freebsd-current Tue Sep 3 05:54:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA27011 for current-outgoing; Tue, 3 Sep 1996 05:54:49 -0700 (PDT) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA27006 for ; Tue, 3 Sep 1996 05:54:47 -0700 (PDT) Received: from downlink.eng.umd.edu (downlink.eng.umd.edu [129.2.98.182]) by po1.glue.umd.edu (8.8.Beta.0/8.7.3) with ESMTP id IAA12739; Tue, 3 Sep 1996 08:54:43 -0400 (EDT) Received: from localhost (chuckr@localhost) by downlink.eng.umd.edu (8.7.5/8.7.3) with SMTP id IAA17889; Tue, 3 Sep 1996 08:54:42 -0400 (EDT) X-Authentication-Warning: downlink.eng.umd.edu: chuckr owned process doing -bs Date: Tue, 3 Sep 1996 08:54:41 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@downlink.eng.umd.edu To: Richard Wackerbarth cc: gjennejohn@frt.dec.com, current@freebsd.org Subject: Re: Latest Current build failure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 3 Sep 1996, Richard Wackerbarth wrote: > >IMO production level means release, not -current. I don't think that > >we can expect to grow a market based on -current, that's what the > >releases are for. People who want to be on the bleeding-edge and use > >-current have to enter this particular "hell" with open eyes. Using > >-current isn't for the faint of heart or newbies. I've been running > >-current for years and have never encountered a problem which wasn't > >quickly remedied in the tree or which I couldn't work around with > >little effort. > > > >I personally don't see investing a lot of time or resources to > >guarantee that -current is ALWAYS compilable. A hiccough now and > >then is what one has to expect and be prepared to accept when using > >-current. > > Well, "release" is not good enough for production. A release is static. > There are always things wrong with a release. They need to be fixed. Newer > versions of utilities need to be incorporated, etc. > > The present "stable" model could fill that slot. However, I would like to > see a bit more effort placed on its support. (I know it isn't as much "fun" > as working on "current") > > To me, there is a tradeoff between getting more "current" testers and > allowing "current" to fail to compile. I personally think that "current" > should be dropped. CVSup of the total tree is appropriate for the "bleeding > edger's". > At least they can then select which parts they wish to include in their build. > The rest can wait for Jordan's SNAP releases. You know, I'm just a little curious about the tone of the argument. While I do think that current has gone through some very bad periods of instability, I don't remember a time that it was as stable as it has been lately. The clear majority of problems in building current have been related to sup archive instability, not current being broke, I think your goals are laudable, but they don't seem to be addressing the problem right now. I am wondering if a rapid checksum program wouldn't be of more general use right now, so folks could elilminate archive problems before complaining that current is broke. I'm running ctm/cvs myself, and current has been incredibly stable. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+-----------------------------------------------