On Thu, 6 Jun 2002, Thomas Dodd wrote: >>I've had a few reports of this now for S3 hardware. There are a >>few different issues here I believe. One, is that XFree86 4.2.0 >>contains a new S3 driver which supports hardware previously >>unsupported by 3.3.6. After discussing it with the author of >>this new driver, I changed the default server to 4.2.0 for the >>hardware that he (Ani Joshi) claimed was supported, after >>confirming it by examining the driver source code. >> >>Here is a deeper problem to solve: >>There was never any intention of shipping XFree86 3.3.6 >>indefinitely. It was only done, so that hopefully, as time moved >>on, XFree86 4.x would mature enough to support more hardware, and >>eventually 3.3.6 would become irrelevant because either: >> >> >This needs to be documented. In the release notes. In the man pages. >In the help system. And espicially in the configuration tools. > >When doing an upgrade/install mention a file on the CD, and ways >to access it, so when a user has trouble with the new >Xserver/driver they know where to look for help. The file(s) >should mention any know problems, like some S3 cards don't work >with the new 4.0 driver, some solutions (get a different card, >use the 3.3.x server, or use the SVGA driver), and a place to >look for updates to the file(@redhat.com). Sure, that is fine for issues that we know about. But the majority of such knowledge is gained _after_ we release, not before we release. These S3 changes were in place about 4-6 months or so prior to getting any bug reports. It is not very easy to let users know stuff in the documentation and RELEASE-NOTES if we find it out 2 months after we make a release. Any and all updates to any files are available via up2date or on updates.redhat.com. That is standard. If there isn't an update available in either location then there isn't any file@redhat.com to update. >This helps for the windows converts who are accustomed to >reboot, reinstall to fix problems. The installer can detect that >the current version is already installed, and offer solutions >instead of reinstalling. I don't understand what you're suggesting here. >>The absolute best thing that any user experiencing problems can >>do, is to report the problem directly to XFree86.org both via >>their bug submission address, as well as to join their mailing >>list and post the problem there (driver issues, etc.). >> >>Bug reports to: xfree86@xfree86.org >>Mailing list: xpert@free86.org > >Mention this first in the help files. include a line like: >If you cannot use the driver, report that to xfree86@xfree86.org >and http://bugzilla.redhat.com. If you workaround the driver, >report how, so it can be adressed in future releases. I plan on improving a few messages here and there to that extent, however... What help files exactly are you refering to? >>Another thing I'm planning on doing is writing an XFree86 >>troubleshooting and debugging HOWTO. A lot of display corruption > >This is a good start. Just make it very visible, and maintained. >If the documentation isn't visible/known it's useless. It will appear on http://people.redhat.com/mharris/ somewhere. Once I've got it minimally ready, I'll put it there and fire an email off here. If it goes well, perhaps it could be moved to our main website in the future. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris
