From: lidl@sura.net (Kurt J. Lidl)
Subject: Re: some gripes about 1.3d
Organization: SURAnet -- 8400 Baltimore Blvd, College Park, MD 20740
Date: Fri, 17 Apr 1992 17:00:30 GMT

potter@silver.lcs.mit.edu (Robert Potter) writes:
>lidl@sura.net (Kurt J. Lidl) writes:
>>>Just tried 1.3d for the first time.  Compiling it went relatively smoothly,
>>>other than the #$%&^@ include-order "feature" in the Imakefiles (really,
>>>guys, if so mamy systems are "installed wrong", can't you just put in a
>>>workaround?!?).
>>
>>What can I say?  I didn't screw up your system.  You fix it.
>
>That's a wonderful attitude for an "official" maintainer to have.  I figured
>you'd care more about making the program generally useful than about spreading
>the gospel of Correct System Installation.

Why?  You cannot expect anyone, either in their free time, or in a paid
environment to support things that are wacked-out.  Most vendors, bless
their proprietary little hearts, don't want to hear about 3rd party problems.
I've gotten the response to inquires before to remove all "local OS
additions" before installing software.  That's rediculous.  However, requiring
a non-broken environment isn't too outrageous, in my mind.  Especially when
most (if not all) of the problems with the X11 include files are due
to inexperienced people mucking about with their install sequence
when *they* install X11.  IE -- it's not even the vendors who have screwed
the customers (as if often the case), but rather the customers screwing
themselves out of a running, robust system.

>>>Oh, yeah, gnat failed to compile (on SPARC):
>>>
>>>/: write failed, file system is full
>>>compiler(iropt) error:  write_irfile: No space left on device
>>
>>Yeah, configure your system with more temp space next time.  Again,
>>your system is broken, you fix it.  Anyone could read the man page
>>for "cc" and notice the glaring "-temp=/some/big/partition" flag
>>there...
>
>Calm down.  Did I say it was your fault?  No.  Should I be treated like a jerk
>because gnat needs more than the 2 meg I have free in /tmp?  No.  Should a note
>mentioning this possible problem be part of the distribution?  Probably.
>Should gnat's author be aware of this possible problem?  Yes.

The original message sounded exactly like "gnat.c didn't compile from me,
so it must be broken for everyone."  Hence my rather testy reply.  Not
to mention, that the author did warn everyone that compiling gnat does
take a lot of space, both temp and swap.

>>>Other first-blush gripes:
>>>
>>>	Show/Pictures is broken.  Layout blown by new additions, and it only
>>>	animates when you move your mouse.
>>
>>Yup -- I noticed this the day after we released it.  Haven't tracked it
>>down yet.
>
>The layout problem is because of the additional items.

I think that Josh & Gordon squished things together, which explains
the chopped up bitmaps.  This whole system is slated for improvement.
Don't know if anyone will get around to doing this for the next
release.

>The animation problem is a side effect of the removal of polled X event
>input (probably).

Almost certainly.  What I meant (but did not say adequately), is that I
haven't tracked it down enough to fix it (but I know the root cause of the
problem).

>>>	Panzy bitmaps need fixing.  Trike bitmaps STILL need fixing (badly).
>>
>>Feel completely free to send in new bitmaps.
>>
>>>	Lots of half-baked features.  By that I mean poorly documented,
>>>	incompletely implemented, and game imbalancing.  I include my own new
>>>	skidding code in this category (because of the bugs, mea culpa).
>>
>>Well, oddly enough, Xtank is a beta system.  You want to fix things
>>fine.
>
>Now wait a minute here.  Why should I be burdened with fixing things that I
>don't think should be there in the first place?

Well, you can also send us a patch that lets you compile with -DNO_BROKEN_CODE,
that effectively stubs out the code that you don't like.

>If you guys add a feature to
>Xtank, shouldn't I be free to say I don't like it?

Absolutely.  Try doing with a little more sugar.  If I get home from
work, and hack on the Xtank code for a couple of hours (trying to
hack in another 3 patches and a new longjmp() system [and end up in a
bad mood, 'cause the %(*^& longjmp() hack isn't working]), fire up
"rn", and find something that rankles with me, you can expect a
flame.  I'm human, subject to my emotions sometimes getting the
better of me.  When I'm tired and frustrated, I'd much rather see
"Gee, here's a couple of bugs.  Here's what I think went wrong.", then
"gnat.c is broken.  Relying on correct include order is stupid. etc".

>As "official" Xtank maintainers you guys are doing a great service
>for the rest of us, and I really do appreciate that.  But don't
>forget that you also have some responsibility to the rest of us
>(namely not to break Xtank).  You should be making some effort to
>make sure the changes you implement are improvements, and not just
>toss in every random patch that somebody sends you.  I'm just voting
>for a little more conservatism when you guys make your judgements
>about what features are worth including.

By and large, with something as big & complex as Xtank, it's awfully
hard to wedge all sorts of changes in without screwing up something.
We work under a lot of constraints.  Most of the work on Xtank gets
done from 10pm-2am range of hours -- after a full 8 hour day of work,
plus commute time.  If we didn't think it worthwhile, we wouldn't work
on it.

Contraints that we work under:

	1) Keep Xtank fairly stable.  This is so people who are not
god-level hackers (have you ever met one of them?  I'm talking Chris
Torek level here...) can install Xtank and have it work.  Not to
mention that Xtank must be in a state where we can at least minimally
debug it.

	2) Another contraint is that we wanted to get new code out the
door so that people who are working on things can work off newer
code, so that they have a prayer of making changes that can be merged
back into the system at a later date.  (In case you haven't noticed,
but I've screwed up some of the patches that have gone into the game,
simply 'cause patch gives up.  Then I get to try and hack in the
patch by hand.)

	3) Add new features, so that people will not be alienated,
and go off and create "Xtank-foo".  (Where foo varies from site to
site.)  This sometimes means adding features that are unbalancing,
and later tuning them to bring them in line...  If this has a general
effect of pushing new features into the game at too high a rate, then
we will continue to have flakey releases.  I don't think that the
release was too bad -- we got a lot done, and a lot of new features
were added.

	4) Try to test all new features before shipping the next
snapshot.  We test on the equipment we have access to.  It's still
only sun4/decstation hardware (we've been trying to get the SVR4
machine working, but are *still* having OS problems!).  I'll let you
in on a little secret here.  The UMD/PIX people are pretty much
combat bigots.  You can bet that Xtank will never ship from us with
combat mode borken.  We don't play Ultimate, so we don't end up
checking that code (rigerously, if at all).

	5) Drive the Xtank system in the direction that we've stated
over and over again.  IE -- towards a more distributed system, with
the hopes of a wire protocol and a real suite of programs, for
designing, setup and so forth.  This should make it more tractable to
the novice Xtank hacker, and should make the entire system easier to
track bugs in.  Since nobody else is working in this direction, the
burden of this falls to us.  (I hope that I'm not sounding too
martyred here, I don't mean to, really.)

	6) Merge back changes that people send us, so that Xtank can
run on more platforms.  This often means adding sections of code that
we have *no way* of testing, for other systems...

>I know I'm free to go off and support my own version of Xtank, but I think
>you'll agree that there's a heavy cost to that (for everybody, not just me).

I know.  I think that the cost is too great.

>Look at all the divergent versions of Xtrek.

I'd rather not :-)

>Remember the useful features from MIT Xtank that were lost when
>UMD Xtank became the "standard".

However, look at the features that were gained, also.  The whole
MIT/UMD thing was before my time -- by the time I started doing
anything at all, the code as already at UMD.

>>Don't just gripe, do something.  I know that you have contributed in the past.
>>Part of the new thing in the next release is a major re-hash of the
>>documentation, to docuement new features and caveats about the code.
>
>I have already rewritten some of those documents twice, and I'm tired of it (as
>I'm sure you are too).  All I'm saying is that those who WRITE the code should
>DOCUMENT the code.  I'd rather have a simple game that I can use than a
>feature-laden one that I can't.

Yes this should be the case.  Some of the "missing" docs are from
Xtank people here at UMD/PIX.  As such, we are going to try and make sure
that the docs get a good whacking that more or less accurately snapshots
the current system.  That hasn't been true in ages.
 
>Sorry if I sound flaming again.

Not a problem.  If you didn't complain, I wouldn't know that you still
like Xtank :-)

								-Kurt
-- 
/* Kurt J. Lidl (lidl@sura.net)       | Unix is the answer, but only if you */
/* X.500: Power Tools for Power Fools | phrase the question very carefully. */