[ Date Index ][
Thread Index ]
[ <= Previous by date /
thread ]
[ Next by date /
thread => ]
On Thursday 18 November 2004 8:30 pm, Mark Evans wrote:
Often an independent third party can help with finding bugs. In the same way that proofreading of a piece of fiction is often best done by someone other than the author.
Very true - this is a powerful reason for peer review of software and the progression of free software options. Every GNU/Linux user should aim to learn enough about the system to be confident in making bug reports on their most commonly used applications. Developers won't bite (unless you waste their time), your reports are essential to future development. Filing a bug report involves scanning the existing reports and seeing if your problem matches. If it doesn't, file a new one. (If it does, follow the thread to fix the problem). Even if you don't find a bug, submit a RFE: request for enhancement. One VERY useful task is quite simple for any user. Reproducing bugs. Once you are familiar with an application, join the mailing list and ask about helping with reducing the number of bug reports by filtering out those that are already solved, those that are artefacts of some local problem and those that are simply junk (usually because the bug report is ambiguous, confused or just noise). You don't need to know a lot about the code, just be able to compile the latest version of the code from CVS and follow the instructions in the bug reports. See if you can reproduce the same bug - if not, that bug can be marked 'unreproducible' or 'fixed'. This is a very important service.
Anyway security is not the same as functionality. "Debugging" tends to be primarily concerned with making a program function correctly.
It depends on your definition of correctly! You see, the 'problem' with free software is that people use it in unexpected ways. Because the source code is available and easily modified, your base code can find it's way into subtly different applications. Developers know this - in many cases that's precisely how their own project started! The consequence is simple: There is a powerful incentive to make code robust and predictable, generic and flexible. You just know that some bright spark is going to use it in a new way and you'll get a bulging email inbox if you don't make it extendible and useful. Alternatively, if you insist on keeping your project narrow, that same bright spark will just fork the project and there'll be another yet another alternative. If you want to get things done in the free software world, you'd better be clear which way you are going to turn. These are tough objectives and take considerable effort but it comes naturally to a community interested in open standards, standards compliance, inter-operability and freedom in general. I'd say the majority of debugging effort is in keeping your options open. It's all to easy to make a quick hack that blocks development of a parallel or tangential process. In a world where users become developers and developers are users, functionality is more than just the number of widgets. Functional code is about extensibility, usefulness, flexibility, robustness. Making the code functional for a mixed audience of developers and users is a far higher target than just adding functionality for users, especially if those users only ever see the binary, not the gargoyle of code behind it. -- Neil Williams ============= http://www.codehelp.co.uk/ http://www.dclug.org.uk/ http://www.isbn.org.uk/ http://sourceforge.net/projects/isbnsearch/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
Attachment:
pgp00035.pgp
Description: PGP signature