Re: AN IMPORTANT MESSEGE FROM SYMBOLICS SOFTWARE SUPPORT

[Brad Miller <miller@CS.ROCHESTER.EDU>]

    Date: Fri, 18 Aug 89 14:59 EDT
    From: pan@Athena.Pangaro.Dialnet.Symbolics.Com (Paul Pangaro)

    I respectfully ask that all those interested in software bugs and
    fixes read the following and respond. 

Well, I'll respond to this (since noone else has jumped up and down yet),
though I've already been vocal on this issue...

I think that it is a waste of my time to run into bugs that have already
been detected and have known workarounds, particularly if I end up spending
much time characterizing the bug for customer-reports (in order to provide a
coherent, terse, bug report), but also when I could have taken steps while
writing the code to avoid the buggy features... I think for the money we as
a site spend on software support, Symbolics 1should0 be informing us of known
bugs, known workarounds for these bugs, and a way to easily get patches as
they are available.

The current system (of reporting a bug, possibly further characterizing it
for a software tech, and finally maybe getting a patch they have for this
problem) is inefficient; if I know there are problems and patches related to
the area, I can load up the relevant patches and then see if I can reproduce
the bug without spending inordinate amounts of time getting reliable
failures, or spending the time of a software tech...

This is something I think would save symbolics time and money (since there
will be problems I can solve completely off-line), and me time and money as
a software subscriber (since there will be problems I can avoid getting
into).

Independantly, I think SLUG can address this issue for those who are NOT on
software support, or as an adjunct to this service (since I presume
Symbolics would only want to distribute patches to those on support):

Slug could set up a database (like listserv on the bitnet) that would allow
customers to report apparent problems, query for known workarounds and
possible patches that customers themselves have supplied. This is similar to
the mechanism I outline above; the difference is that in the first case, it
is Symbolics engineers that are writing or certifying the patches (or
providing workarounds) and providing them to subscribers as part of the
software subscription service, in the second case it is purely a customer
function with no involvement by Symbolics (or blessing on the patches for
that matter). 

The only thing to be sure of in the second case is that Symbolics would have
to provide (or OK) a user authorization list for accounts that have signed a
PLA and would thus be allowed to download patches to Symbolics code. (Users
who had not done so should still be able to use the database of known
problems and workarounds, just not download modified Symbolics code).
Obviously this is not an issue in the first case, because presumably only
maintainance customers would be able to access the system in the first
place.

Comments?