Date: Tue, 21 Jan 1997 14:56:24 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Terry Lambert <terry@lambert.org> Cc: julian@whistle.com, khetan@iafrica.com, hackers@FreeBSD.ORG, freebsd@iafrica.com, danielc@iafrica.com Subject: Re: Terry Message-ID: <19361.853887384@time.cdrom.com> In-Reply-To: Your message of "Tue, 21 Jan 1997 13:37:00 MST." <199701212037.NAA19913@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> You made such a number of factual errors that it was not worthwhile
> taking you to task over them.
I often feel the same way. I guess it's not all just one-sided then.
> For example, you stated that I had not submitted anything that was
> accepted since the LKM system, totally ignoring patches to various
> FS components (like fsck and NFS itself), the "free inode isn't"
> workaround, and the massive init_main.c changes (which were my design).
This was simply a mistake of memory for which I apologise, not a
malicious attempt to deny you credit for code actually written.
In fact, it's interesting that you bring this up since it proves, in a
sense, that we are clearly NOT simply standing in the way of all
commits with "Terry" labels on them as you have implied on other
occasions. But let's move on.
> Terry would argue that just because someone lives in Tucson and
> they want to drive to Salt Lake City doesn't mean that they shouldn't
> drive to Flagstaff: it's on its way to the right destination, and
> moves you closer, even if it isn't itself the destination. Quit
> bitching about my code when I figuratively drive to Flagstaff. I
If you were simply going to the right destination by a slightly
different route then this analogy would hold and we'd have little
excuse for asking for different directions. However, that's really
not the case here and I have it on good authority from those who've
actually seen your patches (I have not) that this is not a simple
matter of Terry deciding to drive off the highway for 10 miles and
along the scenic route. This is Terry submitting patches in such a
way that they are more or less impossible to review (unless you're the
author, but then that's not much of a review now is it?) without more
time and energy being expended that our reviewers have to spare.
I believe that Poul-Henning has also offered you a complete machine to
place your sources on, in their *entirety*, if the task of breaking
the changes down in a way that others can easily follow is simply
beyond what you have the time or inclination to do. If you are
sincere about our requests for decomposition being the only obstacle,
then I strongly urge you to contact Poul-Henning after reading this
email and take him up on his offer. He has already stated several
times, the last time being no more than half an hour ago (on another
list) that he'd be more than happy to review your work even in its
complete, unfettered glory if you're willing to put it up somewhere
where he can actually get at it.
I cannot see how a more reasonable offer than this could be made by
anyone.
> For the longest time, the tools used by the FreeBSD project were not
> capable of supporting concurrent branch developement unless you also
> had commit access to send changes to yourself, or unless you were
> willing to reintegrate changes on a weekly or even daily basis.
But with CVSup this is no longer the case and hasn't been the case for
several months now, so I'd expect that you'd certainly want to avail
yourself of the tools which this project has now provided for the
specific purpose of supporting divergent development (among other
things). You can keep your own branch in a single CVS repository and
not have CVSup clobber it when merging the project's changes back in.
If you need more details on doing this, I'm sure that John Polstra
would be happy to explain it.
> Now, in order to make the changes palletable to people unable to
> grasp the destination from a compass heading, and with them unwilling
> to discuss anything but what fast food place we should eat at when we
> get to the destination, I must make the journey from here to there
> in incremental stops.
No, I have already given you two alternatives which would let you
drive it all in one stretch with nothing but a bottle of benzadrine
and a plastic jesus hanging from your rearview if you so choose. The
offer of a repository machine for your work has been made. The tools
have been written to support independant branch development in a CVS
repository. Whether or not you now choose to avail yourself of these
options is up to you, but please don't say you were never offered any
alternative but a stop-n-go introduction of your work.
> Forgive me if I can't take 2 1/2 years of research and make it look
> palletable to you when you have divided trays with tiny little
> comparments in which you insist any meal served to you must fit,
Talk to Poul-Henning. Send him a tape or FTP the bits to his machine.
We'll take the whole turkey or individual slices, it's really up to
you.
> You can't even agree on what a good design would look like beforehand;
A good design for what, Terry? Since you're using food analogies
here, let's say I'm a Chef. You ask me:
T: "Hey, Monsieur Jordan, exactly how do you prepare your meals and what
sort of planning do you do before you start?"
J: "Well, what sort of meal, Terry, and for how many people?"
T: "That shouldn't matter. Your planning framework should should be
entirely decoupled from the nature of the meal since all dishes can be
mathematically quantified down to their essential components, grouped
by cooking time and the region of the kitchen you will need to prepare
each type of dish, a time-and-motion simulation of the process also
clearly revealing the optimum number of trips to the freezer and the
order in which the components should be extracted. One you have that
information, it's a simple matter to multiply the process demands by the
number of desired dishes and cook the meal. Your inability to
easily answer the question simply points to a flaw in your
operational principles, and I strongly urge you to examine them
thoroughly before you do real harm to your kitchen."
J: "But people love my cooking already, the restaurant is successful,
and I don't do any of that crap."
T: "Ah, but consider that McDonalds is able to produce a Big Mac in
10 minutes or less while it takes you at least half an hour to prepare
a 4 course dinner. Their product is also prepared at 1/10th the
cost and they have several thousands restaurants world-wide, whereas
you only have one. Ergo, there is something they're doing right and
you're doing wrong, and it falls to you to examine your process
carefully if you are to succeed as they have."
J: "I must have a really sharp knife here somewhere.. No jury would
convict me, I'm sure of it."
The analogy may hold more amusement value than direct applicability to
our current situation, but I think that the general point holds - your
"solutions" are rarely practical, and often suggested for problems
which (we feel, at least) exist only in Terry's head. I don't want to
make Big Macs or own a chain of tawdry "restaurants" all over the
planet, I just want to make good food for an appreciative audience.
You want a Big Mac, go to the golden arches. You want a nice meal in
a smaller setting with less patrons (far fewer of which, it might also
be noted, are busily carving on the seats or the other customers) then
come see me.
> As a specific example: The failure to even define what an acceptable
> build system should look like so that there is some reasonable
> assurance of acceptance of the work, after the effort is to be
> expended on spec., has blocked out at least two "warm bodies".
Now hear this: Nobody, and I repeat, nobody is going to define an
"acceptable build system" for you or anyone else. "Acceptable" in
this particular context means "works for all our tools and solves
problems which are unsolved by the current build system" (or there
wouldn't be much point in doing the work), and if I'm going to do all
the work of designing a new framework, verifying that it works for all
the conceivable build situations and is architecturally sound, then
I'm bloody going to go the rest of the way and implement it, no doubt
to find other problems with my logic along the way - nothing else
makes much sense. The definition *IS* a very large part of the work
and expecting someone to do this for you is just ludicrous.
That's why you and Richard haven't gotten anywhere with the new build
system. Richard claims he needs carte-blanche with the build tree to
do a number of unspecified and yet-to-be-defined things to it, none of
which he's been willing to even put out for review. You want a spec
to follow or some sort of "happy meal" in a convenient box, but who's
going to do the work of providing you with all of that? And having
done all that work, why wouldn't they simply follow through with it
themselves rather that trying to wet-nurse another engineer through
their design?
Neither set of demands is reasonable or even constitutes good
engineering, and were I to agitate for similar sweeping changes to the
build system myself then you can bet that *I* would also encounter
significant and justifiable resistance from within the core team until
I'd truly explained to their satisfaction how I wasn't going to break
the entire world or replace it with something far worse. The build
system is one of those special examples of something which effects
practically *everyone*, and if you're prepared to contemplate such
changes lightly (or expect the core team to do the same) then you're
not thinking very clearly, nor have you even shown yourself willing to
explain it to *anyone*'s satisfaction. How could this do anything but
fail?
You also consistently fail to grasp the concept of incremental
introduction. With very few exceptions, the people in the core team
and commit list were chosen after long experience with their work,
most of which started "small" and gave everyone an easy opportunity to
look over their shoulders, so to speak, and see how well they did the
work. You and Richard have never really given us that opportunity,
demanding immediate entrance to the inner sanctum or nothing, and your
own most significant contribution to the project, LKMs, came in a
rather round-about fashion as I recall and I don't think that you
personally oversaw its incorporation or have shown yourself in any way
willing to subsequently work on incremental improvements to it at all.
Is it any wonder that we have grave reservations about your being
willing to work within a group? You have given very little indication
that you even have an interest in such matters, and proving otherwise
would be the simplest thing in the world. Just start contributing
regular fixes and improvements and if you need a map, simply consult
the PR database - there is more than enough material there to keep you
and Richard busy for months, and if you're too good for such work then
we definitely don't want you because closing PRs is a fundamental and
very necessary part of this project's work and we all have to do it.
Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19361.853887384>