On Sun, 2005-06-05 at 15:53 -0700, Chidananda Jayakeerti wrote: > Thanks for the comments so far. I do understand the task is > monumental. However, if drivers are being written and maintained for > hardware, maintaining a compatibility list should be possible and will > be immensly use to users. When looking over a writing project for FDP support, I think of two main things: a) Is it focused on and useful for Fedora? b) Will the writer(s) have some reasonable chance of success? Perhaps when we are a more established project with a number of successes, we might be in a better position to change b) somewhat. This concern about success is not as much for the project as it is for the writers themselves. Our most valuable resource is our writers, and burning them out on nearly impossible tasks is not good. Here are the ideas that don't sound feasible right now: * Hardware Compatability List * Hardware Incompatability List * Driver List by release The arguments against each of these ideas are compelling. Looking at that list, I also see that they are far from short, task- based documentation. Believe me, no one wants to get *paid* to maintain these lists, we surely don't want to volunteer to do so. These ideas sound useful and could be persued: * Short addition to relnotes about how to find help with a user's hardware combination. * Tutorial on the same, but more complex. Talks the reader through discovering exactly what hardware they have (including booting with a live CD in order to get hardware details before installing), explains how to find out the latest details on that hardware, and presents how-to information on many of the common commands useful in making hardware work. Some common examples such as the ipw2200 or synaptics drivers would be appropriate. * True automagic that will take a snapshot of what drivers we apparently ship with, done as part of the release notes build. In essence, a long list of what you find through the config tool when you are configuring a piece of hardware. * Dedicated hardware beat writer for the release notes who keeps on top of nasty combinations known to do evil things and clever fixes that tend to work (ide=nodma for example). The fact is, our true hardware (in)compatability list is always and only within community knowledge. By the time we take a snapshot of that knowledge, it will have changed. Think of one of the lists as akin to a list of places to go fish. It can never truly tell you what you will find when you get to a fishing hole. Nor does it tell you *how* to be successful at fishing. Chida and others who are interested in resolving the hardware problems Fedora users face -- I think the better challenge is in teaching users how to fish. It will not solve any number of particular problems, but it will help to solve many times more actual problems. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-docs-list@xxxxxxxxxx To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-docs-list
