[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How do I report a bug?

The first thing you should do regarding reporting bugs to Symbolics is
to find out what your software maintenance contract calls for.  In
some cases you may have telephone support and/or mail support.  If you
only have telephone support then you can call in bug reports.  I don't
have much experience with this because I find it more useful to send
mail messages.  I should also point out that there are only certain
contacts at your site that will be responsible for communicating with
Symbolics.  You should find out who they are and go through them.
Often those will be people that can solve simple problems and know how
to report a bug so it will be solvable.

Customer-Reports@Symbolics.COM (well, maybe you will need a specific
host like VERMITHRAX.SCH.SYMBOLICS.COM) is the mail address.  I've
suggested that they use the address "Customer-Support" to make it
consistent with the organization you call when your hardware is
broken, but that hasn't been done successfully.

Of course you shouldn't expect help out of Customer Support unless you have
software support but, in my opinion, that shouldn't prevent anyone from
reporting bugs.  You should tell Customer Support enough so they can react
appropriately to the bug:  (from a message from Customer Support)

> In order to be able to
>address the most critical situations expediently, in future messages please 
>indicate the urgency of this message on a 5-level scale of importance --
>	(1) Critical: (No further progress can be made until problem is resolved.)
>	(2) Important: (Work can proceed, however answer or workaround is needed.)
>	(3) Informational: (Request for information or explanation is required.)
>	(4) Bug-report (No immediate response is expected).
>	(5) Feature Request: (No immediate response is expected).
>This will help us to prioritize the messages that we receive, and quicken the 
>response to the messages that are most important to you.

I would also like to point out that there has been a lot of traffic on
SLUG that I think should have gone to CUSTOMER-REPORTS first.  Amongst
those messages in the last month, the original messages about the
following probably should have gone to CUSTOMER-REPORTS:
Carry Tape Bug, SCT/Defpackage Question, Define Command Question,
7.2 Terminal Woes, TCP/IP, Problem with Screen Refresh, SCT (:type
:text), Read-Char-No-Hang, SI:FULL-GC & Optimize World,
SCT:define-distribution-system, the latest message on disk ECC error,
fs:set-logical-pathname-host.  (Originator's names left off
intentionally to avoid flaming.)

Symbolics has software support to help the customers.  It doesn't help
us (the customers) to have queries that are within the scope of
software support to be sent to SLUG and then have someone within
Symbolics answer them.  I hate to see developers spend their time
answering questions that customer support could answer.  Yes, you do
currently get answers faster through SLUG than through customer support.
But that will stop happening if readers of this list get bored of wading
through such stuff.  We have hundreds of readers spread across the world
and a number of them are paying for their mail traffic.

I suggest that we generally adapt the following criteria.  If you are
having a problem with Symbolics supplied code, send a message to
CUSTOMER-REPORTS.  If you don't get an answer sufficient for your
needs, then ask the SLUG mailing list.  If you think the problem would
be of general interest, then go ahead and send the problem (and
solution, if one was available and doesn't involve sending out
Symbolics code) to the SLUG mailing list.  Of course, messages that
don't deal with Symbolics's software (eg, requests for parser
generators) are appropriate for SLUG.

By the way, if you have a problem with a mail address, you might ask
SLUG-REQUEST@AI.SRI.COM (ie, me) before asking the whole list.   Also,
whenever you reply to a message, do consider whether you need to reply to
the whole list or just the sender.