On Mon, 10 Jun 2002, Thomas Dodd wrote: >>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. >> >> >I've never seen an updated RELEASE-NOTES though. > >Perhaps a VIDEO-NOTES, that is keep up to date as bug reports come in >It has a link to www.redhat.com/video-7.3.html, where the most up to date >information can be found. For example, you have had several reporst of S3 >problems, but where does a person go to find out about them? >Or where to get suggested fixes? >Put the know ones on the CD, and new o9nse added to a static location >mentioned in the file on the CD. The amount of effort required to do so, compared to the amount of impact it would have minimizing questions, etc. for those who randomly were lucky enough to find it, is IMHO not worth the effort required. If someone wants to know what has changed WRT video, the answer is "absolutely nothing" if there is no erratum released, and if there is erratum released: rpm -qp --changelog XFree86-tools.....rpm You don't need to download 100Mb of RPM's to do that either. You can download the smallest RPM package from an updated XFree86 and query the changelog. Please note, I am not discounting the usefulness of the information you're suggesting be added. I am merely saying that producing such information in an effective manner and distributing it to people would require more resources than the benefit it would provide. "Benefit" being defined as benefit to minimizing technical support queries, developer queries, and questions asked on mailing lists, etc. Yes some people would read and appreciate it, however I seriously doubt it would cause a halt to incoming questions of the nature. Resources are scarce as it is. However, if someone volunteers to create such a list, I'd be glad to look it over. >>>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. >> >A hook in anaconda, aimed at windows users who think >reinstall the OS is a normal solution :) > >If I'm installing RHL-7.3, and I already have RHL-7.3 >installed, ask me if I would like to start a trouble shooter. >This then displays help files and weblinks to fix subsystem >problems. Like the VIDEO-NOTES, that may have been missed. That is a bit of a futuristic idea IMHO. With merit, but a way off in the distance. >>I plan on improving a few messages here and there to that extent, >>however... What help files exactly are you refering to? >> > >The VIDEO-NOTES file above. When you find the "use SVGA server" >suggestion, mention to report you needed it. The file that has the >suggestion is the best place to mention reporting the issue. The major problem with a file such as VIDEO-NOTES is that it would have to be maintained vigorously. Also, it would likely be expected to be accurate, however would likely not be completely accurate simply because we do not have all video hardware available at our disposal, and if we did, we can't possibly test each piece of hardware in every motherboard out there and in combination with every other piece of hardware which could possibly conflict, let alone dualhead/triplehead or worse 16 head cases. Yes - I have had a bug report from someone having a problem with 16heads being used. Unfortunately, but quite realistically, the solution to that problem is basically "when you solve the problem, send us a patch". We don't have video walls to test on, with specific hardware. ;o) I already *heavily* comment the XFree86 changelog, and I do so specifically so that people who want to know what has changed, have a fully accounted record of it. I'm not willing to update 8 different documents. One is plenty. Also, sometimes something believed to be "fixed" and marked as such in the changelog, turns out to not be fixed 3 months later when someone finally provides feedback, or turns out to work for one user or not another (like the old Banshee ramtiming issue). A fix for one problem might end up causing a different regression. Ultimately, my developmental builds which appear in rawhide and on people.redhat.com are intended for users to beta test. They're unofficial, and I'm not willing to get ultra-end-user detailed about it. If a user wants to use them, I expect them to be able to figure it out mostly on their own, and to query the changelog, etc. I try to help out when I can if someone gets stuck, but I've got work to do too. In the case of our officially released updates, we send out errata emails via RHN, and also to people who subscribe to our redhat-watch, and other mailing lists. We have web pages dedicated to errata, which contain the full text of an erratum notice, and users can read those to obtain information. If more detailed information than what is in the errata notice is needed/wanted, the rpm changelog of any of the rpm packages will provide the most details. If something isn't in the errata notice, or changelog, then it generally isn't known. So, VIDEO-NOTES == errata notices + changelog. If someone wants to compile a page detailing it all, again - I'd be glad to look it over for technical accuracy. Also, think about SOUND-NOTES, USB-WEBCAM-NOTES, PRINTER-NOTES, etc. and you'll see how this becomes an unmanageable problem. Another case is: 1) user reports Savage driver bug(s) 2) someone reports a new driver fixes some bugs 3) I update the driver, and hope it fixes stuff 4) I have no Savage hardware to test with Was the problem fixed? Perhaps, but it isn't easy to give a specific 100% answer. And a doc like VIDEO-NOTES will be taken by many people to be much more of an official word. We simply can't give the type of info that would be IMHO required in such a document because quite simply we don't know. Even the XFree86.org site lists video hardware as supported, but most of it isn't tested because nobody has it or nobody has time to test it all every new release. >>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. > >While those of use who follow the list know about the >people.redhat.com site, the users who are likely to need the >information don't. So they need a big message that tells them to >look there. The message is automatically emailed to you if you subscribe to redhat-watch-list. Anything appearing on people.redhat.com is provided purely for convenience of users and for testing. I'm not willing to excessively burden myself by making myself more work to make it more presentable. It's basically thrown-over-the-fence hope-it-works-for-you stuff. If it is problematic to enough people that it is not documented in excruciating detail and in a format that is easily useable and end-user-friendly, I can remove ~mharris/testing entirely, and defer people to wait for offical updates which do get their proper erratum documentation. An hour spent writing web pages or text files is an hour I'm not fixing bugs. -- 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
