From owner-freebsd-hackers Sat Apr 19 01:38:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA02896 for hackers-outgoing; Sat, 19 Apr 1997 01:38:06 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA02891 for ; Sat, 19 Apr 1997 01:38:02 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id IAA09614; Sat, 19 Apr 1997 08:37:52 GMT Date: Sat, 19 Apr 1997 17:37:51 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: FreeBSD Hackers Subject: Re: Accomodating Terry In-Reply-To: <199704182053.NAA02753@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 18 Apr 1997, Terry Lambert wrote: > If (A) or (B) could be accomodated with a seperate branch, a seperate > branch would be sufficient. I question the difficulty of "going > mainstream" with a part of the code in such a branch (it seems that > you would end up with unacceptable all/none choices), or of it being > able to "keep up" with mainstream developement: > > mainstream -------> branch > | | > | v > | branch > | + > | local changes > | > | > mainstream -------> branch <<< How can this happen > + + without a code slave? > changes local changes > + > changes > > If this is an imagined hurdle, it'd be nice to know. > Merging in changes can be a pain, but it's pretty obvious that this is how it's done around here. For example, Jeffrey Hsu quietly worked on Lite2 and people are now working in merging it into Current. FreeBSD accomodated his working style too, it seems he didn't want random people sending him mail so he quietly went away, worked on it, and came back with it and said go with it. If you had a CVS repository to work on complements of FreeBSD.ORG like SMP you could at least get a publicly available base of code that people could download and pound on. I don't think it matters that much that you get a little behind on the mainstream, you don't need to sync up everyday. FS code has been pretty stable until recently, but you can wait a little bit until it stabilizes again to take a CVS snapshot, branch off and go with it. Regarding the code slave issue, heck even our resident VM guru has worn the "code slave" hat. If it's beneath you to be a code slave then consider that if people like the results then there will be enough code slaves around to merge in the results. ;-) I recommend concentrating the per-fs vnode allocation and some interface cleanup. Forget about transitive closure and the NT HAL for some other time to maximize your chances of success. Regards, Mike Hancock