From owner-freebsd-hackers Sun Dec 10 06:49:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA15840 for hackers-outgoing; Sun, 10 Dec 1995 06:49:47 -0800 (PST) Received: from DATAPLEX.NET (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA15835 for ; Sun, 10 Dec 1995 06:49:45 -0800 (PST) Received: from [199.183.109.242] by DATAPLEX.NET with SMTP (MailShare 1.0fc5); Sun, 10 Dec 1995 08:49:49 -0600 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 10 Dec 1995 08:49:41 -0600 To: hackers@freefall.freebsd.org From: rkw@dataplex.net (Richard Wackerbarth) Subject: Sup's Freefall-centric tree conventions Cc: jkh@time.cdrom.com Sender: owner-hackers@FreeBSD.ORG Precedence: bulk I feel that the group is making a big mistake by using /usr/src as the location of the -current tree available for sup'ping. This assumes that the system is interested in only the absolute latest -current version of the source. I think that this is in error. /usr/src should be reserved for the system's own sources. They might be 2.1-RELEASE, for example. Similarly, assuming that -stable is on /a/src is equally freefall-centric. I advocate that we designate another tree location for the various source trees. For example, ~FreeBSD/current, ~FreeBSD/stable, ~FreeBSD/cvs, etc. The individual system is then free to make these entries links to whatever location is appropriate for their configuration. While we are at it, -stable should not be a tree in its own right. It is really an alias for some other branch. As a result, I would place the tree in ~FreeBSD/2.1 and link ~FreeBSD/stable to it. This is particularly important when you consider that we are likely to have at least three trees active at the same time. These would be the STABLE-RELEASE, the new STABLE-CANDIDATE, and the EXPERIMENTAL/UNSTABLE (-current) trees. I can envision that each of these trees might be changing at the same time if an important security bug fix were to be found while we are still shaking out a new stable-candidate. ---- Richard Wackerbarth rkw@dataplex.net