Joey Hess suggests that using the word “stupid” or using imperatives like “fix it” in bug reports is not a good way to get your bugs looked at. However Gunnar Wolf gives a recent example of an aggressive bug report that made him care.
Popularity: 72% [?]
August 19th, 2007
Gustavo R. Montesino has released his Google Summer of Code project bug-triage, which according to the release announcement has these features:
- Added integration to upstream BTSes
- Added support to more advanced queries
- Added support to followup to a bug
- Allow selection of columns to show
- Added sorting support
- Allow to select the BTS access method to use (SOAP/BTS)
Popularity: 67% [?]
August 19th, 2007
OpenQA is the home of several open source testing tools, notably Selenium, for automated testing of web applications in a number of browsers, including the major ones.
Popularity: 91% [?]
July 5th, 2007
Sebastian Kuegler has a post on releasing KDE 4, and mentions briefly how the bug tracking tool could be used to clarify the release process:
What we can do to make it easier for vendors to ship the next version of our software is making it clear what needs to be done before a release. That would mean: “Here’s a list with what the next release will look like, if you want to make it happen earlier, help us hacking” This could be as easy as recording this in bugzilla, marking it as “showstopper” or “required for x.y.z” and then make the query showing those entries easily accessible through, for example, a direct link.
Popularity: 81% [?]
July 5th, 2007
Luis Villa writes about Infotopia, information-gathering, and software QA, comparing QA problems in open source and proprietary software:
Quite simply, the big problem in QA is getting information about the state of the software out of the software and into the hands of developers as efficiently as possible.
This has three aspects: creating the information, getting it in the hands of the QA teams, and then filtering it into a form that is useful for developers to work on. Traditional QA has a very hard time getting the information… In contrast, open source QA has a whole ocean of information from the legions of volunteers willing to run pre-release code; the trick is to tap into that water without drowning in it.
Popularity: 74% [?]
July 5th, 2007
One bugtracking system that has popped up since I was last posting here is Canonical’s Launchpad.
In mid-2006 James Henstridge talks about Launchpad in the context of it being considered as a bug tracker for Python (note that Python eventually chose Jira and then switched to Roundup). You can also check the more recent Feature Guide to Launchpad.
Popularity: 79% [?]
June 19th, 2007
Jeff Waugh wants to report bad search results to Google, but where? His commenters have some good suggestions:
Scott Says:
June 17th, 2007 at 18:49Perhaps you have to be logged in to get this form?
["Dissatisfied with your search results?" form]
Willem Says:
June 17th, 2007 at 20:48Or bether yet (with some googling ;))
Popularity: 99% [?]
June 18th, 2007
Terence M. Colligan writes:
Although I thought I understood the importance of quality, and took pride in the quality of the software we produced, I never believed that delivering defect-free software was possible. After all, everyone knows that all software has lots of bugs, right?
Well, no, not necessarily! Certainly, most experiences with today’s software quality are not encouraging. Although few people can name even one piece of software which they use that has no bugs, defect-free software is possible to create. We know it is possible, because we’re doing it.
It started with a single engineer. This engineer was consistently producing work with a defect rate more than one hundred times smaller than our other engineers. She has done so for us for over three years now. During the same time, she has produced three to five times as much code as any other engineer.
I found this so exciting that I determined to find out how she did it, and to see if we could teach our other engineers to achieve the same quality results.
Via James Gregory, Defect-free code.
Popularity: 88% [?]
June 16th, 2007
James Gregory reviews how to check for resource pressure bugs.
A quick one for today, sparked by recent events at work. It can pretty much be summed up in this even quicker question: do you know what your program does when it’s out of resources? Out of RAM, out of disk-space, out of address-space, out of time? Computers are indeed powerful beasts these days, and there’s a bunch of people who would like you to believe that they are effectively infinitely powerful, but observing your code working with limited resources, even if those limitations are artificially imposed, can tell you a lot of things you mightn’t have known previously.
Popularity: 86% [?]
June 16th, 2007
Scott Berkun’s Project Manager clinic discussion group had a look at the politics of bug fixing in September 2005:
I quickly realized that my team wasn’t prioritizing for itself - but was prioritizing bugs around management and other perceptions of how other people in the organization would *force* us to prioritize bugs. So in essence my development team wanted to make pre-emptive political choices when it came to bug fixing. Any advice for making this process less frustrating?
Responses review the standard way to prioritise bug fixes.
Popularity: 88% [?]
June 16th, 2007
The Bug Blog links to a different bug every day.
Popularity: 67% [?]
June 16th, 2007
This site is up for adoption.
Popularity: 60% [?]
April 3rd, 2007
Scott Berkun, author of The Art of Project Management, has a series of articles on deciding which bugs to fix:
He argues that:
Here is the golden rule of organizing bugs: fix bugs in the order most likely to result in success. Sounds obvious, right? Wrong. I’d bet that more than half of the buggy and unreliable software you’ve ever used was that way not because the developers didn’t have time to make it better; they simply fixed the wrong bugs. Wanting to fix the right bugs and knowing how to do it are two different things.
He describes four approaches to bug prioritising:
Popularity: 70% [?]
January 20th, 2006
There’s quite a lot of guidelines out there on how to report a security vulnerability in a responsible way as a third party, but not so many on how to report and publicise a fix if you are a software author. (And recall, many software authors are part-time hobbyists, not corporations bankrolling a security team.)
Karl Fogel’s Producing Open Source Software: How to Run a Successful Free Software Project book has some guidelines:
Most open source projects have settled on approximately the same set of steps to handle this conflict between openness and secrecy, based on the these basic guidelines:
- Don’t talk about the bug publicly until a fix is available; then supply the fix at exactly the same moment you announce the bug.
- Come up with that fix as fast as you can—especially if someone outside the project reported the bug, because then you know there’s at least one person outside the project who is able to exploit the vulnerability.
He goes on to detail the process of being assigned a CAN/CVE number, notifying important or particularly vulernable vendors or customers, and making a public announcement.
Popularity: 71% [?]
October 27th, 2005
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: 71% [?]
July 31st, 2005
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: 71% [?]
July 30th, 2005
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: 85% [?]
July 26th, 2005
Ben Goodger argues for the use of Mozilla binaries rather than vendor binaries because binaries have security patches applied earlier:
If security is important to you, this demonstration should show that browsers that are redistributions of the official Mozilla releases are never going to give you security updates as quickly as Mozilla will itself for its supported products.
.
Christopher Aillon criticises this as bad practice:
Other projects make sure that the vendors know of a security vulnerability, supply the patch and new tarball (if applicable, which it is in mozilla.org’s case), give a brief period of time for the vendors to catch up, and then do a synchronous release with them at a planned time.
(via Slashdot)
Popularity: 70% [?]
May 23rd, 2005
Havoc Pennington describes the coordinated release process for security bugs:
The simplest thing is to quietly notify any of the major Linux or BSD distributions and let them take it from there… Once you notify someone, wait to hear back. The upstream maintainer would normally announce the vulnerability and commit patches to CVS at the same coordinated time that vendors post packages. If you patch in CVS before anyone is ready with packages, your users are vulnerable during the gap (and generally unhappy about it). Worse, by committing a patch to CVS you’re doing something that a black hat could notice, but most sysadmins will not notice.
Popularity: 100% [?]
May 23rd, 2005
Rick Schaut describes the process of finding a bug in Word 6 multiple undo that caused a file descriptor leak.
Popularity: 69% [?]
November 5th, 2004