[comp.windows.x] list of bug fixes

dana@dino.bellcore.com (Dana A. Chee) (06/28/88)

I've noticed from time to time people have mentioned bugs by number
(such as bug #450).  Is there a list of found bugs and fixes available
for public browsing?  It would be nice to know that a bug that you are
about to spend significant time tracking has already been found and
possibly a fix exists as well.  I realize that the fixes for these
bugs haven't been blessed, but if something is wrong, and you were
going to have to go in and fix it anyway, much time could be saved.



--
+*************************************************************************+
*  Dana Chee				(201) 829-4488			  *
*  Bellcore								  *
*  Room 2Q-250								  *
*  445 South Street			ARPA: dana@bellcore.com		  *
*  Morristown,  NJ  07960-1910		UUCP: {gateways}!bellcore!dana	  *
+*************************************************************************+

RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (06/29/88)

    Date: 28 Jun 88 15:39:26 GMT
    From: dana@bellcore.bellcore.com  (Dana A. Chee)

    Is there a list of found bugs and fixes available
    for public browsing?

Not from MIT, except for the public fixes provided by anonymous ftp and
the xstuff server.

    It would be nice to know that a bug that you are
    about to spend significant time tracking has already been found and
    possibly a fix exists as well.

It is nice.  The MIT staff of the X Consortium provides bug reports and
fixes (more than the public sees) in a timely manner to Consortium
members.  Except for "critical" fixes, the public must wait until the
next release.

ado@elsie.UUCP (Arthur David Olson) (06/30/88)

In article <19880628214032.0.RWS@KILLINGTON.LCS.MIT.EDU>, RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) writes:
> The MIT staff of the X Consortium provides bug reports and
> fixes (more than the public sees) in a timely manner to Consortium
> members.  Except for "critical" fixes, the public must wait until the
> next release.

Well I feel just awful. . .only two weeks of being an X user and already
I've blown it.  Here I've been sending off bug reports willy-nilly to 
xbugs@expo.lcs.mit.edu, only to learn now that the correct behavior is to
"wait until the next release" before reporting noncritical bugs.  I'll try to
do this from now on.  (And, of course, my first report following the release
of Release 3 will be to suggest that an admonition to "wait until the next
release" before reporting bugs be included in the System Release Notes.)

In any event. . .I'm thinking of setting up a mailing list for folks interested
in timely sharing of X bug reports.  I'd like to honor the Consortium's policy,
so I envision that this list would be limited to people who are not associated
with the Consortium and who would refrain from forwarding items to the
Consortium.  If you'd be interested in being part of such a list, let me know.
-- 
	ado@ncifcrf.gov			ADO is a trademark of Ampex.

RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (07/01/88)

    Date: 30 Jun 88 13:27:23 GMT
    From: elsie!ado@cvl.umd.edu  (Arthur David Olson)

    Here I've been sending off bug reports willy-nilly to 
    xbugs@expo.lcs.mit.edu, only to learn now that the correct behavior is to
    "wait until the next release" before reporting noncritical bugs.

I can't quite tell if you are confused or just being snide, and your
comments may have confused others, so I'll take a chance and respond.
We aren't suggesting you postpone reporting of bugs.  We hope you will
report bugs of all sorts as you find them.  However, our experience has
been that disseminating bug reports too widely is a big mistake, because
"the public" tends to believe everything they read and will apply
suggested "fixes" that tend to break more than they fix.  I suspect the
majority of people on this list don't really want to see the volume of
bug mail we receive; xpert has a low enough signal to noise ratio
already.

If you don't like the fact that we don't immediately post any and all
fixes we make, sorry.  I think you'll find that is true of most
organizations trying to maintain large software distributions.  It is
canonical that no matter how you provide as a free service, somebody
will complain that it isn't enough.