Being a newbie, I'm not sure how the Linux development process works, but I suppose there are stages something like this:
- New hardware or new commercial software or maybe just a stroke of genius inspires someone to develop Linux software; - People who have similar inspirations get together, agree on the basic design of the new programs (and an approximate division of labor if it's not a small project); - They develop and test the software, updating the design as new problems or opportunities arise; - When it "works," at least most of the time, it is released, that is, a beta version is posted, and other people are encouraged to try it; - If it becomes reliable and proves popular, it gets included in commercial vendors' distributions. Since Linux is used on many hardware platforms and software configurations, it is not feasible to test new software packages in all the environments in which they will be used, but developers will prefer to test on reasonably "ordinary" systems rather than unique platforms that make things work differently from what cooperating developers expect. At the same time, it is unlikely that all the developers will be working in exactly the same environment. What I am suggesting is that a developer should provide a script that displays a description of the hardware, the source of the Linux package, the versions of the kernel and any other relevant software, and any changes to environment variables in the test system. Then a script of the installation and testing of the package should be recorded. If cooperating developers can do this in a variety of environments, so much the better, but at least one successful run should be recorded. With an example of a successful test installation, the user can then try to do the same thing, observe where the paths diverge, and concentrate analysis on that event. Even if help is needed, the supporting analyst does not have to scan a random assortment of logs, config files and tables supplied by the user. Of course, it would be educational to supply comments that explain to the user what is being done at each step and why it could fail, but it is not absolutely necessary for the developer to write any documentation. The recorded success both reassures the user that it can be done and identifies the step at which the different environment causes a divergence from the desired result. Eric Peabody ------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
