Date: Sat, 19 Apr 1997 17:37:51 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Terry Lambert <terry@lambert.org> Cc: FreeBSD Hackers <hackers@freebsd.org> Subject: Re: Accomodating Terry Message-ID: <Pine.SV4.3.95.970419170350.9526A-100000@parkplace.cet.co.jp> In-Reply-To: <199704182053.NAA02753@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.970419170350.9526A-100000>