[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Symbolics Software Support
This is in reply to Jerry Bakin's message "Re: A bug with defconstant?".
Things we've been banging our head against for years...
Symbolics doesn't really have the staff to give out many individual patches.
I think their idea of customer support is to listen to people and determine
whether it is a bug in their code or in the way you are trying to do something.
Fine, but then if it is a bug in Symbolics's code, they don't usually send out
patches. (Occasionally they can't as the patch is too pervasive.)
The Software Support Contract Service is defined to include a
subscription to the software technical bulletin (distributed in hardcopy
approximately six times a year). Symbolics SHOULD be sending out those
bulletins. But we all know that Symbolics is having hard times and the
question often is what things can go that, while they impinge on current
needs of the customers, may allow the company to weather its roughest
times. I would rather the company survive
One of the sore points between customers and Symbolics has been the
restriction of sources. Not just the lack of some sources but also the
restriction that one PLA (Program License Agreement) holder can not give
any form of Symbolics code to another PLA holder. This prohibits me
from sending to others patches for bugs that I have found and fixed
myself (whether or not my fix is the one Symbolics would choose).
Symbolics and SLUG Inc. have a method for distributing larger pieces of code
that contain Symbolics code. I applaud this but it is somewhat cumbersome
and doesn't allow for relatively quick bug fix distributions.
Perhaps this is the time that Symbolics could consider alternative methods of
allowing users some supporting of other users. If Symbolics doesn't have the
current manpower to help users with bugs in Symbolics' code, then maybe they
can let other users help with that support.
A suggestion: Let Symbolics maintain an electronic mailing list (at
Symbolics) that only goes to those people with PLAs. This would not be
a direct mailing list but instead would be one in which someone from
Symbolics reads the incoming mail and redirects it to the appropriate
mailing list of customers with PLAs. (That way, SRI wouldn't get to see
anything about PASCAL since we haven't bought that product.) The header
of each message sent out would contain whatever legalese that would make
the contents not be redistributable. (eg, "Portions of the following
message are copyright Symbolics and may not ...") Thus I couldn't take
the message and forward it to someone outside my own company (or
whatever legal entity that holds the PLA). All outgoing messages would
have just a TO: address of the list itself (incoming mail sent to that
address wouldn't get sent out automatically). The FROM: address could
be the incoming address. There would be no CC: addresses.
This would allow the customers to distribute bug fixes, albeit
indirectly. We legally send them to Symbolics and Symbolics sends them
to the appropriate people. Of course such mail would not contain any
stamp of approval by Symbolics. If I sent in mail describing a patch I
made, others would see it but it might not be what Symbolics would
suggest (whenever they got around to fixing it or explaining why what I
thought was fixing wasn't a bug).
I have heard people from Customer Support say that we users don't want to
see all the mail that they get. That may be true, but some of us would
rather wade through the drivel than to run into problems that have been
solved elsewhere. The mailing list I am thinking of would not overlap with
Customer-Reports. Ie, if I wanted to ask about how to do something, I would
send mail to Customer-Reports. If I wanted to report a bug (and patch) to
a standard system function, I could send my report to Customer-Reports and