The Bugzilla Changelog application has been updated to work with bugzilla 3.0. Please try it out and let me know if you have any issues.

Download Bugzilla Changelog 1.2.

Seventy-percent of my work day is spent in a code editor. For years I tried out every single application listed until I finally discovered PSPad. One of the requirements I needed was a ‘save all’ option to save all currently open files, and the ability to search & replace in files – open files, or files in a directory.

Now, I have the problem of being split between two apps. For years I’ve also used Zend Studio, and now that I finally have a computer that can handle it’s resource requirements, I can’t decide which app to use. Zend Studio has amazing code completion, even completing classes/functions/variables from other places in the project. It increases productivity and dramatically reduces my trips to the php.net documentation to lookup the exact syntax of a function.

I’ve forced myself to use it exclusively for several weeks now and I’m finally getting used to it. PSPad had the ability to search and replace in files on disk, while Zend Studio only replaces text strings in open files. PSPad also had a toolbar button to toggle word-wrapping. When editing text I frequently need word-wrapping, but when I’m programming I usually turn it off. Zend allows me to toggle it, but only after getting to its location in the preference pane first.

I’ve been using VMWare so that I can test IE6 as well as IE7 (which is the default on my actual machine). VMWare takes a lot of system resources, and with the laptop I use at the moment, it requires a few items to be closed so that it will work properly. I’ve read about several manual hack-ish methods of getting both versions of IE to work on a single machine but I just didn’t want to bother with all of that.

Enter MultipleIE.

An excellent system that allows me to install multiple versions of IE at the click of a button. I no longer support IE5.5 or it’s predecessors, so I just installed IE6. It works very well! I’ve noticed that it shares it’s location bar history with IE7, but they render things as you would expect each to.

Thanks to one of my development partners for pointing me to that.

Brand New! The shopping list generator:

http://www.botsko.net/Demos/shopping_list/

View Mantis in use.
View Bugzilla in use.

I began using Mantis in mid-2002 when I first began developing complicated PHP applications. It was nice to start out with and had some useful features, but as the years passed and the projects came and went, I really found out what I liked and didn’t like.

Interface

In early 2005 I started using Bugzilla for projects at Wells Fargo, and immediately I found it more to my taste. Both were relatively easy to setup, although prior knowledge of CGI file permissions is required for Bugzilla. I found Bugzilla easier to read – it had a cleaner interface that was easier to customize. The colors and plain text was very easy on the eyes and was laid out in a manner that made a bit more sense to me. The excessive whitespace in Bugzilla really helps separate the fields, whereas mantis connects them all in several large tables which draws my attention to corners and sections of the page that I shouldn’t even look at.

As of the 2.20+ releases of bugzilla, it’s easier to change certain field values without editing any config files. In mantis you need to edit a php file in order to change some of the field options, as well as the more advanced options. Bugzilla lays all of the major options you might need into a single page, and allows you to access a web-based interface for changing certain field values.

In addition to a better templating system, Bugzilla makes it easier for you to customize it.

Tools

Bugzilla has a much better report tool, as it provides better customization of report queries, and has much more powerful reporting code. Mantis can show some excellent statistics by default that might take a minute to generate in Bugzilla, but Bugzilla makes up for that by having a much more powerful set of tools.

Mantis sends update emails when actions are taken on bugs, which is a great feature to have. Bugzilla has a feature that I cannot live without – whining. Setting up scheduled, automated emails with saved searches is an excellent way of reminding someone about bugs that need some action taken. There is also a default whine available to remind yourself about bugs that have sat around too long – I don’t see any type of automated email reminder system in Mantis.

The single tool that I LOVE bugzilla for are the Flags. The ability to flag (or “label”) a bug and run searches off of those flags is a feature that I have come to rely on. I can set a bug as “follow-up” or “possible-fix-needs-testing” or “blocking-some-release”. The ability to set labels like that make bug management and reporting a lot easier. The lack of this feature is the one thing that really makes using Mantis difficult. To properly manage my bug queue I need to be able to keep the bugs separate, while keeping them assigned to me. Labelling a bug as “awaiting approval” would be so helpful, so that I can easily spot and begin work on bugs not yet waiting for anything.

Other Usage Differences

I think Bugzilla has a better advanced search interface, providing more dynamic options. Javascript is effectively used to update the advanced search panel fields when you make certain selections. It’s a bit easier to create new searches as well as edit existing items, and it’s easier to access searches you’ve saved. Mantis allows for saving of “filters” but that’s about it. While useful, it requires a bit more work when saving and using multiple filters. Also, I don’t believe that mantis allows you to bookmark your search.

Mantis seems to have several steps in a process that don’t need to be there. I don’t want an entire page to tell me “Operation Successful” after I do something. Bugzilla displays a page that confirms the change, but also shows either the bug you just edited or the next bug on the list, reducing the number of pages I need to click though. When I view a bug in Mantis, I need to click an edit button before I can edit it, but by default, not all of the fields are available to edit. I need to click edit advanced in order to edit every field available. Bugzilla has a single view page, that allows you edit any field you have without clicking extra buttons.

The last, but maybe least important issue is that Mantis doesn’t have the ability to connect with CVS, LXR, and Bonsai.

Overall

Overall, Bugzilla is just simpler to manage from the reporter, developer, and admin levels. It reduces the time one spends sorting their bugs and managing their queue, which really helps as you have more time for development work. It seems much easier for bugs to slip through the crack with Mantis, as Bugzilla was really designed to prevent that.

The only feature that Mantis has (with versions .19+ anyway) that Bugzilla needs, is the ability to generate change logs. However, it wasn’t too hard to toss together a perl script using the Bugzilla tables.

Update:

03/07/2006 – Two additions to this. Bugzilla will turn bug numbers in your notes into links automatically, while Mantis does not. Bugzilla prints out a list of people notified via email when an action is taken on a bug. I can guess who got an email in Mantis, but I like it when it’s printed out in front of me.

Over the years I’ve tried several bug tracking applications and Bugzilla is by far my favorite. It’s a great tool for all sorts of projects, whether they’re open source or not. It’s proven its ability to handle thousands of bugs for many different projects with ease as it’s the bug tracking tool that the Mozilla Foundation prefers. Yet how can single developers who work on small to medium-sized web-based applications use this tool without sacrificing much time managing it? I’ve worked out which features are useful and which are not to me, as I am one of those free-lance programmers.

Users/Groups

My installation of Bugzilla 2.20rc1 is on a local test server, so there is only one user I have to manage – myself. Right away I really don’t have to worry about user or group permissions, because I just give myself access to everything. Depending on what exactly you contract for, you may need to allow your clients to access and run queries on your database – but that’s not much extra work at all. For my type of business, the technical reports are for me and would be too confusing for my clients. If ever there was a need for them to see details, it’s just a copy-and-paste away.

I really haven’t found it useful to mark a bug either new or assigned, and managing those assignments is pretty pointless with only a single user. For me it’s either unresolved, resolved, or closed.

Products

My products are generally small to medium-sized web-based applications that typically do not take longer than a month to work on. Sometimes I have larger applications that take a year or more of work, so I need flexibility in both my scheduling, bug tracking, and revision control to manage all of my pending workflow. Bugzilla makes it very easy for me to keep track of each project. Each new project I begin for a client, I create a new product for in Bugzilla. My rule on separating code and projects is that if the code I write is completely separate from any other code I’ve written for that same client, it gets it’s own product entry. If I’m just adding a new module to an existing project, I’ll simply add a new component to the product listing in bugzilla.

From there, I just use components, version numbers, and target milestones the same way everyone else does. I do use CVS (maybe someday I’ll go to Subversion) for basic revision control of these projects. My guideline on entering code to CVS and creating a product in bugzilla is that:

• If it’s a small project, I can enter the code once I have a beta (ready for external testing) complete.
• If it’s a large project, I’ll enter it the moment I get a good foundation (I use a framework I’ve created, so pretty much I’ll commit it immediately).

If I don’t follow those basic guidelines I’ll have a huge project with a million things to do – which means I would get sucked into the black hole of entering obvious to-dos instead of actual bugs. A contractor must use their time wisely, and using bugzilla for something more than BUGS is just a waste of time. It’s tough for me to not use it as a to-do list, but it’s much easier to manage issues versus features requests when I stick to that principle.

Tags

The most wonderful thing about bugzilla is the ability to categorize bugs by using labels. These tags make managing my “queue” of pending work amazingly easy. This is where the fun begins.

blocking-1.0.0

Most applications I’ve seen use tags to identify which bugs are so important that the next update/version should be held until they’re resolved. It’s a great method, especially when you use them with the priority fields for individual bugs. Though this is helpful for contractors developing small applications, it’s better to use them to identify bugs that the client has to have fixed before they’ll accept the product. The product may work as expected without some of them being resolved, which is not really what a blocking bug is for, but it’s useful in identifying what has to be cleared out before product delivery.

This tag really must be created for each product.

research-required

I use this tag as a global tag (applicable to all products) to signify bugs I need to research before I can begin any work. Maybe I need to read a tutorial, a reference manual specification, or just peruse some sample syntax. It allows me to easily to see what I need to know before I go in and develop anything. Pulling all products at once with this tag applied allows me to do all of the research when I have time. It also can help me when a client is asking for an idea on how much time remains until I’ve got a product they can look at – if I know I have four bugs and not one clue how to fix them, I can avoid giving a false timeframe. This has been a life saver!

easy-fix

Many project management experts advise you to do something right now if it will take you less than two minutes to complete. This is a very good tip for both real life and the development word. If I have a bug or change request that really would take less than two minutes to fix – mainly layout or text issues – I’ll pull this list and do a fix-spree. How many of these can I clear out of my “queue” in the next half hour? I’m surprised at the amount of bugs I can clear out with a simple pull of bugs with that tag. I generally can focus much better if I do similar work all at once. If I have a list of easy-fix bugs, I can speed through all of them without taking much time to check for potential bugs – as they’re usually so easy that they don’t cause any new bugs to open.

Sometimes I’ve found it useful to also have a difficult-fix tag, to get the opposite listing of bugs. The more bugs you can clear out, the easier it will be to see what’s left. This really helps you plan out how much work you need to do before any deadlines, as well as making it easier to manage a queue of ten bugs rather than twenty.

next-target

Sometimes I’ll take set aside a huge chunk of a day to sit down and power-code. In order to maximize the time free for coding, I need to make sure all my bugs are in order before I do. Just like setting out an agenda for a meeting, identifying which bugs you need to tackle on your next work day is very important. If I scan through my list of bugs with either a blocking-something tag or a high priority, I can mark it as a next-target so that when I come in to begin working I have everything that needs to be done ASAP. I’ll print that report out, post it on the wall, and start the day! I just keep a red Sharpie handy to cross out what I’ve done, so that later I can update bugzilla!

This keeps me focused on what needs to be done now, as I don’t even see lower-priority fixes that I would prefer to work on. It’s really just a tool to eliminate distraction. Then I at the end of the day I can see how many important things are left, and then proceed to feel good or bad depending on my accomplishments.

Whining

I never played with this until recently, and I love it! As a contractor who doesn’t have all day to manage my bugzilla lists, I setup a few whining crons to email me when I have to do something. I see my lists of bugs as “queues” and as any effective-queue management expert knows, you need to keep them moving! I’ve setup a whine to email me a list of all of the bugs that I have not updated in two weeks. I am guilty of deleting one or two of these emails, but it’s important than I have an idea on how behind (or ahead) I am.

I also send myself a list of the bugs with the aforementioned tag “research-required” so if I happen to check email somewhere other than home, I have a reminder of something I could be doing.

What Would Make Bugzilla Perfect?

Previously I used Mantis for bug tracking, so the bugzilla status fields were a bit different and difficult to get used to when I first switched. I’m not at all keen on the bugzilla resolution fields – and how they’re used. I find it very confusing to mark a bug as “RESOLVED” with a resolution of “WONTFIX” or “INVALID” – because if I won’t fix it then it certainly isn’t resolved. Why would I want to mark something as RESOLVED when it’s not? I think there should only be one status field, with:

• NEW
• UNCONFIRMED
• CONFIRMED
• ASSIGNED
• RESOLVED
• CLOSED
• REOPENED
• DUPLICATE

That’s all anyone should really need, and it makes perfect sense.

I also love the way that Mantis utilizes a changelog feature – simply creating basic lists of bugs that are resolved grouped by their target milestone. Bugzilla really needs this. The problem now is that I can do a search for these, but if I change the format of the search results template, it’s changed for ALL search results. A special template and a separate changelog feature would be very handy – but for now, I decided to write a separate (basic) perl script for this.

The whine emails are very nice, but because my power-coding days are never consistent, I would like the ability to trigger an email with the click of a button. I can’t predict when some of these days will be and I don’t want to always be changing the crontab – so manually sending an email whenever I want would be nice.

If I had lots of time (and someday I might not be so busy) I would try to submit some patches to the Bugzilla source and see what the owners think. After all, the open source motto is to fill in where you see a need!

Conclusion

I hope I have outlined some good ideas for independent / free-lance programmers and how they can use bugzilla for their own use. Bug tracking, version control, and other items generally associated with larger projects can often very handy for small-time projects as well! I would appreciate any comments with alternate ideas, comments, and/or suggestions!