Date: Fri, 18 Apr 1997 13:53:44 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: michaelh@cet.co.jp Cc: ccsanady@nyx.pr.mcs.net, hackers@freebsd.org Subject: Re: Accomodating Terry Message-ID: <199704182053.NAA02753@phaeton.artisoft.com> In-Reply-To: <Pine.SV4.3.95.970418110118.28979C-100000@parkplace.cet.co.jp> from "Michael Hancock" at Apr 18, 97 02:19:18 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704182053.NAA02753>