From owner-freebsd-hackers Fri Apr 18 13:55:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA02610 for hackers-outgoing; Fri, 18 Apr 1997 13:55:19 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA02603 for ; Fri, 18 Apr 1997 13:55:13 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA02753; Fri, 18 Apr 1997 13:53:44 -0700 From: Terry Lambert Message-Id: <199704182053.NAA02753@phaeton.artisoft.com> Subject: Re: Accomodating Terry To: michaelh@cet.co.jp Date: Fri, 18 Apr 1997 13:53:44 -0700 (MST) Cc: ccsanady@nyx.pr.mcs.net, hackers@freebsd.org In-Reply-To: from "Michael Hancock" at Apr 18, 97 02:19:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Can we do the new fs technology branch or does somebody have a better > idea? More importantly. Terry, are you even willing to work in a > separate branch of the repository or is Current the only thing acceptable? My main interest is in not having to reintegrate changes over and over and over so that I can do what I need to do, and still benefit from other contributors developement work at the same time. This is basically the justification I give for why commercial entities should contribute their changes back to the BSD they change. The big bottleneck in this right now is that there is no way for me (or anyone else) to assert local version control without committing changes through the main tree and supping them back in my local copy. This isn't a problem for committers because they always commit to the main tree, so the main tree supplies them local version control for no additional effort on their part. This limits me to one of the following approaches: A) The "monoblock" 1) Do a huge change 2) Wait for it to be integrated in some form 3) Perform the next huge change 4) goto 2 B) The "nibble" 1) Do a huge change 2) Submit a tiny part of the huge change 3) Wait for it to be integrated in some form 4) Is the huge change done? No... goto 2 5) Perform the next huge change 6) goto 2 C) The "consultant" 1) Fix a bug from the tracking database 2) Have no fun doing it 3) Wait for it to be integrated in some form 4) Pickup the next bug and fix it 5) goto 2 D) The "take my ball ang go home" 1) Strike off on my own version 2) Diminish both efforts in the process 3) Wait for a similar issue about my own version to piss off someone else sufficiently 4) Have them strike off on their own too 5) goto 2 I don't like (C) or (D) for reasons which should be self evident; I've tried (C) for a while and had one or two successes (like the fsck inode reference count bug when creating "lost+found"), but (C)(2) is the kicker... it may be needed, but not fun. Like a floppy tape driver or the X.25 maintenance, or a new sysinstall; all are needed, all are not a lot of fun (neither's working on the build stuff, which is why the people who volunteer for it want an up front problem definition). I've tried (A) and met with limited success (LKM's, SYSINIT, etc.). I'm currently engaged in trying (B), with code actually getting reviewed by Julian and Sean (so far) but no passing of (B)(3) yet. 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. I'm up for an option (E), (F), or (G), too, if you can see some options that I'm not considering; I'm willing to admit the possibility of a blind spot. I think I'm very like a commercial developer trying to contribute changes back to the main line code base. Actually, some of the changes were made to benefit products or research projects for my current employer ...which doesn't necessarily mean they are not suitable for a wider audience. So for some things, I really *am* a commercial developer trying to contribute changes back to offload the reintegration burden. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.