From owner-freebsd-current Wed Sep 4 23:44:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA26070 for current-outgoing; Wed, 4 Sep 1996 23:44:23 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA26046 for ; Wed, 4 Sep 1996 23:44:20 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA02797; Wed, 4 Sep 1996 16:03:54 -0600 (MDT) Date: Wed, 4 Sep 1996 16:03:54 -0600 (MDT) Message-Id: <199609042203.QAA02797@rocky.mt.sri.com> From: Nate Williams To: rkw@dataplex.net (Richard Wackerbarth) Cc: Nate Williams , current@freebsd.org Subject: Re: Latest Current build failure In-Reply-To: References: Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 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. Which we have now. > 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. Which we have now, except that the sup mirrors are synchronized and the code they have is based on whenver they last updated the tree. Since the 'frequent' snapshots of the tree are just as likely to give the user 'bogus' (uncompilable, unbuildable, crashable) code as the previous method there is no reason to force the mirror sites to use CTM. Note, having a 'standard' distribution directory would be a 'good thing', but it's hard to enforce, even with 'core' apporval since every mirror site is governed by it's own rules. > 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. This can still be done, and I volunteer you to do it. *grin* You can be the 'cookie-man' who keeps a virgin copy of the tree, and when it's buildable you can claim it's the next candidate for 'recent'. Then, all of the 'mirrors' can snarf it from you. As Jordan already stated, WC doesn't have the resources to do it, and since you're so interested in making this work you're the most qualified site to start this. You'll need to get co-operation from the 'mirror' sites, and while you're communicating with them you may want to fix the 'distribution' problem above. I'm pretty sure 'core' wouldn't mind you doing this. Do any of the core members have any problem with Richard being the 'cookie-man', and organizing the mirror sites? Be careful not to impose too much 'policy for the sake of policy' on the sites. Forcing them to use CTM just because you like isn't a justifiable position, since the 'cookied-tree' would only be updated when a new 'recent' tree was OK'd by you, they could choose to get the bits however they best feel is good, and distribute them in the same manner. Nate