From owner-freebsd-current Tue Sep 3 06:01:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA27257 for current-outgoing; Tue, 3 Sep 1996 06:01:54 -0700 (PDT) Received: from eel.dataplex.net (eel.dataplex.net [208.2.87.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA27250 for ; Tue, 3 Sep 1996 06:01:51 -0700 (PDT) Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id HAA14313; Tue, 3 Sep 1996 07:59:18 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Sep 1996 07:59:17 -0500 To: "Jordan K. Hubbard" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Food for thought Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Jordan K. Hubbard" writes: > Nope, that's not my model at all. Please, do not confuse policy which > arises from a reasonable apprehension of the trade-offs involved in > relying on volunteer labor and lots of midnight coding (a frequent > necessity for those with day jobs) with any personal ideal. I'm not saying that you consider it a good "model", but rather that it is the model of the reality of the situation. I'm sure that YOU would prefer something that works a bit better. The Lord knows that you spend entirely too much time transforming this chaos into something that can be sold. There certainly is no "right" answer that satisfys everyone. >Sigh. No matter what trade-offs one takes, it seems, there's at least >one immutable constant: "Ya just can't win!" :-) Amen. There are a few policies that I think lead to some of the problem. 1) Although I like the idea that "current" is readily available, forcing new development to be done against it leads, IMHO, to making people use something which is more unstable than what they need or desire. The tradeoff is in the integration. 2) The relative reluctance to attempt to support "released" systems. There appears to be an attitude of "shipped and forgotten". 3) The extremely short test cycle for new releases. IMHO, we should already have a feature freeze for 2.2 and the leading edge should be planning for 2.3. 4) It's too hard for the "average Joe" to isolate various parallel developments. Often the "unbuildability" of current bounces from one camp to another. Just about the time one problem gets cleaned up, something crops up in another area. 5) Unfortunately, only a few of us can afford to have spare machines to "burn" on instability. How often do we see somebody limping along without adequate HD?