From owner-freebsd-current Sat Sep 16 14:20:07 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA24986 for current-outgoing; Sat, 16 Sep 1995 14:20:07 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA24968 for ; Sat, 16 Sep 1995 14:20:03 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id OAA01903; Sat, 16 Sep 1995 14:19:45 -0700 From: "Rodney W. Grimes" Message-Id: <199509162119.OAA01903@GndRsh.aac.dev.com> Subject: Re: Which SUP files are available and where ? To: rkw@dataplex.net (Richard Wackerbarth) Date: Sat, 16 Sep 1995 14:19:44 -0700 (PDT) Cc: current@FreeBSD.org In-Reply-To: from "Richard Wackerbarth" at Sep 16, 95 03:40:37 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1720 Sender: owner-current@FreeBSD.org Precedence: bulk > > At 2:50 PM 9/16/95, Rodney W. Grimes wrote: > > >This can still be made to work, just change the name from ``stable'' to > >``stable-2.2'' in the sup control files when that tree gets created ( > >I suggest YAST (Yet Another Source Tree) for this, as it might be nice > >to have critical bug fixes go to users via sup who are running 2.1R, > >just cut the cvs and sup updates down to once every 3 days or something > >slightly more reasonable for a maintainence mode tree. > > Why bother with "stable" anything. Just call the tree 2.1, 2.2, 2.3, etc. > As for the long term support, I think we should consider CTM as the > distribution mechanism rather than sup. > > Comments? I can live with those names, names are just labels and are not so important to me any more so long as I have a description of what the label means as far as content. On the sup vs ctm, well, when ctm can fix my tree I just splattered all over I'll switch, until then I will leave it to the others to use. CTM is slightly fragile with respect to anyone doing work in there local tree, while sup has documented mechanism to deal with it (backup is a really nice option, as are old and keep :-). Some how I think it will be a long time before CTM can offer that level of fuctionality. Sup could use some protocol rewrites so that it does things like mass tranfer of the inode update information instead of doing it 1 file per 2xRTT and perhaps some smarts about file moves would help cut load down for things like the cvs repository (files going into the Attic are a pain :-(). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD