From owner-freebsd-current Tue Sep 3 18:13:30 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA12569 for current-outgoing; Tue, 3 Sep 1996 18:13:30 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA12559 for ; Tue, 3 Sep 1996 18:13:28 -0700 (PDT) Received: from eel.dataplex.net by mail.crl.com with SMTP id AA24798 (5.65c/IDA-1.5 for ); Tue, 3 Sep 1996 18:11:59 -0700 Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id UAA21280; Tue, 3 Sep 1996 20:09:02 -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 20:09:01 -0500 To: Michael Smith From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Food for thought Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Richard Wackerbarth stands accused of saying: >> >> >Richard Wackerbarth stands accused of saying: >> >> >> >> 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. >> > >> >Bollocks. -current is _incredibly_ stable for what is a running >> >second-by-second snapshot of a development tree in full swing. >> >> But many would be contributors have absolutely no need for such >> second-by-second access. They need a reasonably current platform against >> which they can do useful work. > >Which is what the -SNAP releases are for. Are you just being intentionally >dim or something? I thought at the start that you actually had some sort >of vaguely coherent idea of what you thought was the Right Way. So far >all you've done is whine about problems that don't actually exist. I disagree about the adequacy of "snap" releases. Jordan seems to get them out perhaps once a month. (I'm not faulting him) There are those who want to help check out things with much less latency, like maybe a day. The only problem is that they don't want to spend all of their time just getting the build to work. I think that Jordan is on the right track with his idea of an automated build "certification" scheme. If we implement such a scheme, it will soon become obvious whether the users are simply "whiners" or that they honestly have a beef. I propose that we divorce "current" from "head" in the sense that "current" becomes controlled snapshots of "head". Anyone who wants "head" MUST get it by cvs. To start, "current" would be "released" the 4 times per day that correspond to the ctm distribution of cvs. At each "release", a ctm-cur update would be generated. This would be the distribution method of choice for those who keep the entire tree and track it closely. (That includes, especially, the -current sup servers which would update in response to the release) As we find some willing machines, we can introduce a "certification" phase whereby the distribution is checked out and compiled. If it passes, notification is sent to release (or encourage the release) of a particular level of "current". Since the ctm-cur generator is the arbitrator of releases of "current", the policy would be implemented there. However, it would not be difficult to allow the reports to be generally distributed so that anyone with a cvs tree could make their own decision.