bug reports (a tad long)

[MILLER@VAX.CAM.NIST.GOV]

   Date: Tue, 31 Oct 89 17:13 EST
   From: JR@YUKON.SCRC.Symbolics.COM (Johanna Rothman)

   I don't have completely accurate information from this past year.  
   [much helpful info deleted]

I, for one, would like to thank Johanna for this information, even if it
is only estimates.  It is helpful for me to get a sense of the scale of
what we (well Symbolics, actually) are dealing with.

    Date: 30 Oct 89 20:42:51 GMT
    From: rshu@ads.com (Richard Shu)

   ...  Here is a strawman proposal for such a mechanism.
   
   Item 1: Provide a way for bug reports that are submitted to
           customer-reports to be forwarded to the SLUG mailing
           list. ...
   
   Item 2: Status reports on bug resolution should be cc'ed to
           the SLUG mailing list. 

I'd cast a vote for this suggestion; It would seem to be relatively easy
for to implement.  Knowing the SLUG community, I'd even bet that
symbolics would get a lot of `free debugging' help: somebody may already
have a workaround, others may have their interest piqued and proceed to
help narrow down where the bug really is, and so forth.  [On the other
hand, I can also imagine that having a lot of prima-donnas telling
Symbolics how to fix the bug could also become a headache !:+)]

On the other hand, SLUG is a bit ephemeral, hosts go down, mail gets
lost or not archived... I would still like to see an archive
maintained by Symbolics that I could peruse. (see Item 3, below)

		...				It is then up to
           interested parties to negotiate with Symbolics for
           the fix.  At the very least, interested parties will
           know how long they can expect to wait for a fix.
   Rich

Proposed Item 3:
  To supplement this, when patches or workarounds are available (which
presumably should not be posted to SLUG), these could be available via
FTP (or somesuch; I dont know what dialnet'ers would use?).  Access
could be based on current PLA's and/or maintenance agreements (via
magic usernames & passwords?).  Although knowing who's got what would
definitely be a problem, it could, in principle, minimize the number of
patches that you have to actively send out.


    Date: Mon, 30 Oct 89 13:39 PST
    From: rsl@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM (Richard Lamson)  

    The last company I dealt with on this kind of issue had a database
    called the trouble-report database ...

Well, I like this suggestion too. But, although as Richard points out,
it would directly benefit Symbolics internally, it also would require
significantly more labor to set up and more time till it is operational.
Also, posting reports to SLUG has the advantage of telling people about
a bug that is ABOUT to kill you!

Therefore:  A Proposal (modest as they say);
  Phase 1: implement richard shu's suggestion. It's relatively quick and
easy and keeps people informed about what bugs there are & status.  And
provide network access to fixes for appropriate users/sites.

  Phase 2: As resources permit, evolve whatever internal tracking system
you have into something meeting richard L's suggestion. Even after it is
brought on line, however, continue posting appropriate info to SLUG.


Just one last point; I hope I'm not running on or becoming to picky. 
I've seen in the discussion phrases like `why they should buy Software
Support..' or `More People might pay for Maintenance if ...'.
Amongst all of these modest proposals for what services Symbolics should
provide, I would also like to have a sense of where people (incl Symb.)
think the line should be drawn between Contract and Subscription
support. 

Thanks for your patience;
Bruce
miller@cam.nist.gov