Ok, a rundown on my thoughts, as if anyone cared. (none / 1) (#33)
by jd on Tue Mar 18, 2008 at 02:52:00 PM EST
- Reusable components are good
- Reusable components should be as low-level in the system as makes sense and no lower
- Inventing new wheels is not a problem, if the axle is a standard - likewise, replacing a software component is effortless if there's a standard way of making use of it
- There are many Open Source GUIs - Berlin/Fresco is one that is amazing - it is the users, not the developers, who have kept X11 alive
- There are many toolkits for profiling software, detecting memory leaks, analyzing resource usage and debugging at the source level. It's unreasonable to ask most users to use these tools or submit in-depth studies on source code to developers, but how many of those users who COULD do this actually do?
- How many frameworks (eg: KDE, Gnome, Motif, FLTK, Afterstep, WindowMaker) provide mechanisms for non-expert users to submit bug reports to the right developers if a third-party application using that framework crashes? Of those that do, how often are the bug reports actually any use?
Suggested actions for framework developers:
- Develop better bug-reporting tools.
- On initial connection to the framework libraries, an application should be able to register a point of contact for e-mailed debug information to go to.
- On initial connection to the framework libraries, an application should be able to register a bug-tracker system (type, URI, and layout of report) for directly filed debug information to go to.
- The framework should be able to record a session of an application. If an application crashes, the user should be offered the ability to automatically re-run that session in a special debug or profiling mode, so that developers can get extra information on what went wrong.
- If a bug-tracker is registered, then all tracker numbers for bug reports to that tracker should be recorded and should also be erasable by the user.
- Provide extra debugging/profiling code, such that when distros build debug and profile versions of the code, there is enough information to be useful.
- Provide mechanisms by which a bug-tracker can be queried.
Suggested actions for application developers:
- Make as much use of debug/profiling hooks as possible in the supported framework(s).
- If automatic bug reporting is supported, make sure that both the feature and the bug reports are used.
- QA the code using unit tests and integrated tests as far as is reasonable. Don't assume that because the code compiles that it works.
- Run scanners over the code, such as Valgrind.
- Link the code to debugger utilities such as ElectricFence or dmalloc (in the case of bounds checking and memory leak detection) and make sure that the code isn't doing something strange.
- Add extra conditional code blocks for when compiling in debug or profile modes to preserve useful information.
- Provide mechanisms by which a user can list closed and still open bugs for that application.
Suggested actions for users:
- Avoid, where possible, frameworks and applications that impede debugging and development. (There's no point complaining about code not working if you can't say anything useful and developers can't do anything with what you do say anyway.)
- Initial bug reports should be from the code in its regular state. This information is inherently very limited, but is the only information users can provide in the case of both unrepeatable bugs and Heisenbugs.
- Users should provide developers with the best information they can.
- If a crashed session has been logged, they should find time to replay that session under as close to the same conditions as possible, but with debugging or profiling enabled.
- If the bug is repeatable, they need to file the automatically collected data and a comment about the circumstances surrounding the crash. In the case of bug-trackers, this should generally be automatically inserted as a follow-up on the original (non-debug) report.
- The user, on discovering bugs in the software, is ultimately responsible for ensuring that the software they use does what they want. If critical (to the user) bugs aren't getting fixed, the user must determine if this means they need to supply additional information, switch packages, or approach things differently.
- The user should recognize that they have no business complaining about bugs they don't supply enough information on for the developer to fix, provided the user is given a means to supply that information.
- The user should complain when genuine, repeatable, adequately detailed bug reports are not handled effectively within a reasonable time. (Reasonable is a function of the resources available. Single developer projects can't fix things in the same timeframe as projects with many active hands.)