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

Re: AN IMPORTANT MESSEGE FROM SYMBOLICS SOFTWARE SUPPORT

Received: from THOMAS.LAAC-AI.Dialnet.Symbolics.COM by ALAN.LAAC-AI.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 4256; Mon 30-Oct-89 14:11:40 PST
Date: Mon, 30 Oct 89 14:15 PST
From: Robert D. Pfeiffer <RDP@ALAN.LAAC-AI.Dialnet.Symbolics.COM>
Subject: Re: AN IMPORTANT MESSEGE FROM SYMBOLICS SOFTWARE SUPPORT
To: SLUG@ALAN.LAAC-AI.Dialnet.Symbolics.COM
In-Reply-To: <9645@zodiac.ADS.COM>
Message-ID: <19891030221558.4.RDP@THOMAS.LAAC-AI.Dialnet.Symbolics.COM>

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

    BTW, aside from providing feedback to the originator of the bug
    report, can we consider mechanisms to provide information to 
    other members of the Symbolics community?  Here is a strawman
    proposal for such a mechanism.

    I assume that customer-reports@symbolics.com is the correct
    destination for customer submitted bug reports.  

    Item 1: Provide a way for bug reports that are submitted to
	    customer-reports to be forwarded to the SLUG mailing
	    list.  This can be done automatically via hacking
	    mail aliases.  Alternatively, Symbolics may wish to
	    exercise some control by forwarding bug reports only
	    when they have been acknowledged as being "real" bugs.

Good idea.  I, too, would very much like to see any reports of known
bugs forwarded back to the SLUG list.  Automatic forwarding would be
okay although clearly it would be much better if they had "official
acknowledgment" from Symbolics.

    Item 2: Status reports on bug resolution should be cc'ed to
	    the SLUG mailing list.  In keeping with the spirit
	    of my previous posting, bug fixes need not be made
	    available to the SLUG mailing list but the availability
	    of the fix should be made known.  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

       
        


    (responsible-p ADS message)
    NIL
    (si:halt)