From owner-freebsd-sparc Wed Feb 9 1:15: 3 2000 Delivered-To: freebsd-sparc@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by builder.freebsd.org (Postfix) with ESMTP id 04F574954 for ; Tue, 8 Feb 2000 21:31:11 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 11DE81CD7; Wed, 9 Feb 2000 13:30:33 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Lyndon Griffin Cc: freebsd-sparc@freebsd.org Subject: Re: CVS server In-Reply-To: Message from Lyndon Griffin of "Sun, 06 Feb 2000 04:18:16 EST." Date: Wed, 09 Feb 2000 13:30:33 +0800 From: Peter Wemm Message-Id: <20000209053033.11DE81CD7@overcee.netplex.com.au> Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Lyndon Griffin wrote: > OK - maybe I'm misunderstanding something, then... I was under the > impression that committing anything into the existing tree was dependent > on having something that worked. Correct me if I'm wrong, but if that > isn't the case, why has the 'early boot code' tarball never been checked > in? Or do I just not see it in the tree? If that is the case, what will > it take to get the existing stuff into the tree? It doesn't have to be finished before it goes into the tree. The situation really depends on the state of it and how much impact it will have on other architectures. If (for example) it mainly requires adding new drivers and fixing portability problems in common code then it's not likely to be a problem to get it into the tree. If it's going to cause breakage on a daily basis then it would have to go into ether a branch (ouch!) until it stabilized or worked on in a seperate tree. It all depends. Also, another consideration is whether the code has enough momentum and people interested in it to keep it alive. If it's going to sit in the tree and rot because nobody wants to do anything with it, then it's pointless going into the tree to start with. (I'm not suggesting that this is the case, but it certainly doesn't hurt to demonstrate that it's got momentum and people involved.) Having it in the main tree for development (without a branch) is probably the optimum way of keeping everyone up to date and in sync. However, if it's going to inferfere with things (for example, the disk labelling and partitioning support) in a big way then we'll have to think of something else. > Thanks, > > <:) Lyndon Griffin > http://www.bsd4us.org > > On Sat, 5 Feb 2000, David O'Brien wrote: > > > On Sat, Feb 05, 2000 at 07:17:31PM -0500, Lyndon Griffin wrote: > > > Can somebody offer a little help in setting up a CVS server? Here's what > > ... > > > the rest using CTM. Any help is appreciated. In fact, I would like to > > > assign someone as the CVS admin - let me know if you are interested. > > > > > > I should have this server on the internet for interested parties to check > > > stuff in in the next week or so. If you have stuff that you would like t o > > > > I fail to see what is wrong the the existing FreeBSD CVS repository. > > What is missing isn't a place to check bits into -- it is the BITS > > themselves that are missing. > > > > -- > > -- David (obrien@NUXI.com) > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-sparc" in the body of the message > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message