Bug Databases - Bugzilla

One of the great things about working in computers is finding technologies that makes your life easier. Finding a good fit for your development process is a bonus, but sometimes you do have to alter your process slightly to get the most out of those tools. One of the best out there is Bugzilla. When working on a product of any size a good bug/request/task tracker is completely essential.

Bugzilla is probably the best known bug tracker out there, but it simultaneously seems to have the Marmite effect on people. It is a scalable, powerful, customisable system for managing a large amount of issues. Certainly at some point in the development process you end up with more bugs than you know what to do with and it requires the ability to categorise and filter, this is where Bugzilla excels.

Recently Bugzilla 3.0 Release Candidate 1 was made available. It adds spades of functionality, like custom fields, read-only fields, an XML-RPC interface, and more than that.

Bugzilla provides a massive breadth and depth of functionality. The bug reports provide loads of information by default, an you can switch off or add to those fields. The main power of the system is the search facility, it is fully comprehensive and daunting to the first-time user. Most people who dislike Bugzilla have an aversion to the search feature, but it allows you to save searches and perform boolean searches, and now with version 3.0 you can assign searches to groups.

It has a powerful group feature where if you are a member of a group the group has its own permissions and settings. It allows you to provide levels like sales, support, development, etc.

You can generate reports via searches, but also there is a set of comprehensive graphical charts. It allows for you to track fixes by version, or by product, or component, and more.

Since it is open-source with all the source code it allows you to make it do whatever you want with enough hard graft. In a previous job I implemented a custom Bugzilla database (based on a beta version 2.18). Basically it involved tidying up the UI, providing per report storage areas via FTP, and a couple more tweaks like combo boxes for user names. In the end it involved importing bugs from disparate sources like a well-structure bug database, Microsoft Access fiels, and even Excel spreadsheets. Bugzilla provides an XML import feature which is invaluable when migrating to it.

With all the features and the proven stability and security (the Mozilla one must be over 300,000 bugs by now), it is a great tool for developers.

Online Code Reviews - Codestriker

Part of the development process at work is code reviews. It is a peer review working as a sanity checker, and provides more than one set of eyes looking at the problem. The process itself is fairly simply governed by an excellent source control system in Subversion (with additional excellent tools like TortoiseSVN).

There is an online tool to help with the annotations and code reviews process. It's called Codestriker and provides a web interface and access to the source control through it. Basically the system provides the ability to annotate source code and allow others to read those notes.

It's good for a formalised system, but is a very comprehensive system. This means that it does take a lot more user interface interaction than a simple email detailing any changes. For a large system with many developers it could be more of an invaluable tool, especially for large quantities of comments. It is also useful if your code is really bad and you need lots of comments ;)

The system also has Bugzilla integration, so stick together this, Subversion, and Bugzilla and you have quite a powerful open-source system.

Take Screenshots on Vista

Here is a great little program for taking screenshots on Vista without the pollution of underlying windows unless you want it to. It is called Window Clippings by Kenny Kerr.

Adobe Development Process

An interesting article came up on The Register about the Adobe development process. It covers the approach applied for Adobe CS3 and how it was successful. Really it was an application of iterative development. You can read the article here.

Vista and system RAM

There is an article here about how Vista handles system memory. It is called "Why does Vista use all my memory" by Jeff Atwood.

Essentially all system memory is now considered a cache (using a system called SuperFetch). This means that the amount of memory used would be as much RAM as is available to cache from the hard-drive.

I don't know if I am completely sure it is a good idea because if a program requires a lot of memory then it has the initial lag to clear the cache in order to service memory requests. Maybe as time goes on the technology will get better, so it may be more usable in the future.