Some of this is in /usr/src/linux/REPORTING-BUGS. On Thu, 29 May 2003 [EMAIL PROTECTED] wrote:
> 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 > -- /------------------------------------+-------------------------\ |Stephen J. Gowdy | SLAC, MailStop 34, | |http://www.slac.stanford.edu/~gowdy/ | 2575 Sand Hill Road, | |http://calendar.yahoo.com/gowdy | Menlo Park CA 94025, USA | |EMail: [EMAIL PROTECTED] | Tel: +1 650 926 3144 | \------------------------------------+-------------------------/ ------------------------------------------------------- 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
