Here’s an entertaining collection of bug reports:
A bug report is sometimes entertaining either because of the personalities involved or because of the bug itself. Here are a collection of links into public bug trackers; I learned about most of these in a recent Twitter thread.
GitHub blog brings us a piece of exciting news – now you can add more attachment types to comments. The list is no longer limited by images alone. Now you can attach Microsoft Word, Excel, and PowerPoint files, as well as plain text and PDF documents. This feature alone will make GitHub Issues into a much more viable bug tracking option for many projects and companies.
Phabricator – code review, browser, bug tracker, and wiki
Phabricator is an open source collection of web applications which makes it easier to scale software companies.
For those people who can’t afford GitHub, this should be a pretty good alternative. Developed at Facebook. All you’ll need to do is setup your git repositories.
P.S.: The best product descriptions ever (for parts of the Phabricator).
Holy Molly! Finally, one of the two things that I’ve been missing a lot from GitHub saw the light of day. From now on, GitHub issues can have attachments. So far, they are limited to only image types, but that’s enough for the majority of the situations. Because that’s what you need the most – a screenshot illustrating the problem.
Now, if only one could open up project issue tracker to general public without playing around with the API, GitHub would be complete and absolutely perfect. But something tells me that’s just a question of time. So, waiting …
Here is a quote from the Google Chrome 12 stable release blog post:
We’d also like to call particular attention to Sergey Glazunov’s $3133.7 reward. Although the linked bug is not of critical severity, it was accompanied by a beautiful chain of lesser severity bugs which demonstrated critical impact.
My focus here is not on the money that Sergey earned with his bug report, even though that is definitely an important and motivating factor. My focus is on the chain of the events. While this chain of events happens pretty much every time a bug is fixed, few people know about it. Maybe nobody, in fact, except for developers themselves.
The thing is that when a bug is discovered and fixed, pretty much every developer searches the code for problems similar to those brought up by the bug report. Be those issues typing mistakes, documentation inconsistencies, memory leaks, security issues, performance bottlenecks, or anything else – the code will be checked to make sure that the same problem doesn’t come up twice. From this perspective, I think that bug reports are so important not because of the specific bugs that they report, but because of those other bugs which aren’t yet fixed and probably aren’t yet reported.
Conclusion: every time you come across a bug in the application, don’t just work around it – take a few minutes of your time to report the problem properly to the developers. Chances are, they will fix some problems that you haven’t yet come across, but have pretty good chances to otherwise.
As I have mentioned a few times before, I am a big fan of using BestPractical RT3 for all sorts of things, including, but not limited to, bug tracking during project development. I see a great benefit in having a single system for both technical support and development departments. Bugs can be reported by customers, investigated by technical support department, passed on to developers, fixed and tested, and then passed back to technical support department to verify with the customer and resolve.
Needless to say, integrating RT3 with Subversion can be of great benefit. In this case, not only you will have full history of bug reports, but you’ll also see which code changes were made for each bug report. Learning from previous bug fixes and having a quick way to see why something was changed is priceless.
Read more to see how RT3 can be integrated with Subversion. You can also easily adopt the same approach to other version control systems.
Continue reading “Integrating RT3 with Subversion”
I’ve been praising Best Pratical’s RT3 (aka Request Tracker) for a long time. So at my new job, given a new start, I thought that I maybe need to explore other options and widen my horizons. After all, the needs were much less and much simpler. We just needed a bug tracking application for three people or so and for a single project. There was a possibility of more people joining the team later and more projects starting up, so I didn’t want to limit ourselves too much. But immediate needs were quite simple.
After a good look around, I decided to give Mantis Bug Tracker another try. I remember using it for a bit back when the project just started. I even remember patching it to fit my needs back then.
During those few years that I haven’t looked at MantisBT it grew and developed quite a bit. It is a stable, feature-rich, yet simple to manage application. We’ve used it for the whole two month before our needs changed again and we started looking back at RT3. Never-the-less I am glad we used it and got experience with another tool. I got a few ideas out of it, which I will be implementing in our new RT3 installation. Below are the few things that I loved and hated about the MantisBT. Maybe you’ll find them useful.
Continue reading “MantisBT vs. RT3”