Software bugs

Jacub Steiner has some tips for bug reporters who are making a feature request (ie asking for new functionality, rather than reporting broken existing functionality):

If you take the time to write a functional specification, you are very likely going to motivate someone to get it implemented. You take the burden of designing the behaviour and let the developer worry about implementation details, data structures, etc. You invest your time and effort just like the hacker would have. Here’s a few suggestions.

• Define the functionality by creating a few test cases on what problems you are trying to solve.
• Be very specific and go through the process step by step. It will make you find problems with your design. If you were to just suggest functionality and don’t work out the details, you will, in the best scenario, waste developer’s time discussing the flaws you would have found yourself.
• It is better to find a bad design while writing the spec than after it has been implemented. Convincing a developer to redo something is close to impossible when he already invested a lot of time in it.
• Be visual. Create mockups of the interface as you go step by step through the process of solving the task. Many times I have thought my descriptions are clear, when they weren’t. Images tend to be less vague (Well this may simply be because my writting sucks, too).

Popularity: 67% [?]

Joey Hess describes the trouble for distros trying to provide security updates for Mozilla:

That’s right, this bug, which is for a security hole that was fixed two weeks ago, is not being dislosed until apparently, August 1st. Same is true for several others of the holes fixed in recent versions. That’s two weeks for distibutions that have to backport these fixes to race against black hats to see who can track down the hole in all the other changes in the new mozilla release, and respectively fix and exploit it.

And so Ubuntu has decided to backport the new mozilla versions into their releases instead of backporting fixes, while Debian stable has decided to bow out of the race. Both understandable decisions in their own contexts.

Popularity: 64% [?]

Nicholas Fitzroy-Dale reviews several bug trackers, and has a list of their common features:

General-purpose features

• Searching and filtering
  • Full-text search
  • Field search
  • Saved searches
  • “Subscribable” searches – get search results emailed periodically or be notified if the search picks up new issues
• Custom fields. Ability to add new trackable fields to issues, search on them etc.
• Full issue tracking. Track issues from the first report to the resolution, including any emails sent back and forth.
• Attachments of images and code

Specialised features

• Import and export: Import bugs from email, from Excel, from Access or other databases; export to a structured text form (CSV, XML) or a database format.

He also discusses how people decide whether or not to use a given tracker:

Reasons given are

• Difficult to set up
• Difficult to change later (ie lack of export option)
• Strange or unfamiliar hardware / software requirements (eg must run on Windows NT, requires J2EE)

Popularity: 66% [?]