(non-)flakey Genera 8.0.1

[KMP@STONY-BROOK.SCRC.Symbolics.COM (Kent M Pitman)]

Now that the discussion has died down about this issue of m-sh-C being
broken, I want to make a couple of quick meta-comments.

First, could everyone please be careful about phrases like 
  "xxx is *BROKEN* in Genera 8.0.1"
where you don't qualify when it worked previously.  This wording
(combined with an overly general subject line like "flakey 8.0.1")
strongly implies that the thing worked in 8.0 and that something major
got broken in the 8.0.1 release.  In fact, the bug referred to in this
conversation turns out to have been introduced prior to 8.0.1 and was
just never noticed until 8.0.1.  (And, in fact, you later admitted 
that you were comparing to 7.2, not 8.0.)

Due to the wording that was chosen in this conversation, it would be
quite possible for someone to have gotten the impression that 8.0.1 is
not a solid and well QA'd ECO.  In fact, 8.0.1 is -quite- solid and it's
really important that anyone who needs any of the fixes it provides feel
confident that loading it will not be just trading one set of bugs for
another.  In fact, as far as I know, loading 8.0.1 is just going to make
lots of things better.

So if you find a bug, and you aren't sure when it came into effect,
please be conservative about your wording.  If you indicate a release
version, please select a wording that makes it clear whether the 
is incidental (i.e., you happened to be running that release at the
time but for all you know the bug has been there since Release 4.5)
or important (i.e., you tried this yesterday in release x.y
and you're sure  it worked fine--then you installed x.y+1 and it 
no longer works).  The same kind of thing happens a lot for people
who report bugs in products like the MacIvory, the XL1200, or 
whatever.  It's important for us to know that you're using a particular
piece of hardware when we track things down -just in case- it's 
important, but that does not necessarily mean that the MacIvory or 
XL1200 or whatever is the cause of the problem.

The second point I would like to make regards the statement:
 "Now, I would send these bug to Customer Reports except that I can't repeat
  them predictably. I can't isolate them down to a small example."
Please, if you are on service, feel free to send something to
Customer-Reports even if you don't have a reproducible test case.  Also,
feel free to send us mail asking if we've seen the bug or are working on
it or have a fix or whatever so that if you're thinking of doing work on
it yourself, you don't have to worry (as someone suggested) that you're
duplicating effort.

It may well be that we can't actually fix the bug from the information
you've provided us, but that doesn't at all mean that we resent your
reporting it.  Sometimes it alerts us to the need for better QA.
Sometimes it alerts us to watch more closely for the symptom in-house.
Sometimes it trigger's something in a developer's mind when he's reading
source code and notices something that seems suspicious and then
remembers someone was having problems with that.

And, of course, it helps a lot if you say in the report that you don't
know how to reproduce the problem, that you know this might not be
enough info to track it down, etc. so that the person who gets assigned
the report knows your expectations and doesn't feel like they're being
asked to do something superhuman.

Well, I've taken up enough of everyone's time.  I hope this info is
helpful to people in the future in order to keep the customer support
wheels turning as smoothly as possible.  Remember--we're all in this
together, so the better we can each understand each other's positions,
the easier it is to get past the misunderstandings and on to solving as
many problems as we can.
 -kmp

p.s. Btw, for what it's worth, here's some mail we got from 
     Mike McMahon which addresses the Add Patch Buffer Changed Definitions
     part of this conversation.  Hopefully this is enough for anyone who
     needs an immediate fix to construct an appropriate private:

       Date: Mon, 27 Aug 90 14:26 EDT
       From: Mike McMahon <MMcM@TITANIA.Oberon.Dialnet.Symbolics.COM>
 
       I think this is a bug introduced into ZWEI:ADD-PATCH-BUFFER-CHANGED-DEFINITIONS.
       It does (or save-tick read-tick).  I think it should do (or read-tick save-tick).
       I think the release 7 code just did read-tick.
       It's only guessing, but I'd say the change was probably introduced to
       fix a bug with new files that had never been read before.

     In fact, I think he's referring to the part that says:
     (SETQ READ-TICK (OR (SEND BUFFER :SEND-IF-HANDLES :SAVE-TICK)
		         (SEND BUFFER :SEND-IF-HANDLES :READ-TICK)))
     which should be the other way around, so as to prefer the read tick over
     the save tick, but to use the save tick if there is no read tick.

     I'm not sure what the status of the m-sh-C bug is, or whether it's
     related, but if you're on service and want to send us mail inquiring 
     about the status of that bug, I'm sure someone will look into it.