From owner-freebsd-current Wed Sep 4 14:54:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA04634 for current-outgoing; Wed, 4 Sep 1996 14:54:16 -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 OAA04624 for ; Wed, 4 Sep 1996 14:54:07 -0700 (PDT) Received: from eel.dataplex.net by mail.crl.com with SMTP id AA03752 (5.65c/IDA-1.5 for ); Wed, 4 Sep 1996 14:52:30 -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 QAA05984; Wed, 4 Sep 1996 16:50:00 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Sep 1996 16:50:00 -0500 To: Nate Williams From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Latest Current build failure Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Nate Williams writes: >I think you give too much 'power' to the 'powers that be'. You're >completely free to do anything you want. But, *FIRST* of all show a >working prototype and *THEN* expect to be heralded as the hero. > >Put the cart before the horse, not the other way around. Not in this case. This involves a policy change for the distribution of FreeBSD. THere is no way that I can modify the distribution channels without the "blessing" of the 'core'. What I propose is to have three tiers of distribution. At the top, we have those who either have direct access to the master tree or are willing to live with CVSup'ed images taken from it. At the next level, we have frequent snapshots of the tree. These are clocked by the ctm-cvs generator (every 6 hours, I believe). I would have the sup mirrors use this as their distributable product. The third level would be the "current" (or as someone said, "recent") tree. It would also be synced to the above mentioned distributions. However, the distribution can be delayed or skipped until some verfication of the "buildability" has been established. Initially, we can simply ignore "buildability" and release the updates on arrival. Later, we can put a release filter into the mechanism. The entire process is implemented with existing and tested components. I have now done as much as I reasonably can do without authorization to actually implement the scheme. Since this was previously presented along with the offer to coordinate the effort and has been rejected without explanation, I again present it as evidence supporting my attitude and refuting yours. I cannot do "what I want". Neither can I demonstrate a working modification to the make system without first removing a bunch of inappropriate absolute file references. But I cannot get anyone to agree to make those changes until I demonstrate that it all works. So which is the chicken and which is the egg in this case?