What system do you use for bug tracking? | Hacker News Reader

What system do you use for bug tracking?

7 pointsACSparks35 comments

I am interested in seeing how you track bugs during development and acceptance testing.

We use bugzilla, but it leaves a little to be desired.

Trac ( http://trac.edgewall.org/ ) is awesome. It also has very good integration with subversion, if you want that (but you can ignore that aspect if you just want a bug-tracker).

There is a local company Assembla.com that has a basecamp like online project management service. it has Trac as one of the features. I am using it for our project, which includes a couple of developers in the Boston area and a couple in India.

We also use Trac (for a ~8 person engineering team). Works great: very convenient to have a wiki, bug tracker, and SVN browser integrated together in one nicely-designed piece of software.

Trac is very nice, as other have stated. It's kinda like SourceForge done right, in the sense that it has source browsing, a wiki for web pages, and a bug tracker with good notification capabilities. Last time I used it it was absolutely retarded about user accounts and saving settings (you had to carry around an MD5 "key", rather than being able to log in).

We're using FlySpray, because it drops into our CMS (Joomla) with relative ease, and we wanted customers to be able to file bugs. We also use it for support. It works pretty well, has all of the features we needed, and is a really nice clean and simple codebase, so customizations are relatively easy. It's also a low-dependency PHP project, so it'll drop onto any ol' hosting account with a database, and runs plenty fast.

Comments at the top of the file.

On personal projects I use comments like

    (defun foo (x y z)
      ;; FIXME: foo should not barf if x is nil

and then periodically grep all my sources for "FIXME".

This is so common that many of the syntax files for Vim even have TODO FIXME XXX NOTE and others included, so they're highlighted and easy to spot.

Going for full Notepad(tm) compatibility, eh?

IMHO, poor thinking. (sorry)

how will you prioritise and track them - open up all the files?

 grep FIXME *.l | sed s/^;;// | sort -n

still poor thinking (sorry again).

- what about bugs that dont belong to one file; and those that are across modules?

- to edit or reprioritise, you must open up the files again. Imagine making a Project Manager or business guy learn vi, not to mention messing up your code!

I work defects into my status report. It is just another heading - and move them around the categories. (template: http://juwo-works.blogspot.com/2007/08/my-status-report-temp... ).

Check out Roundup - http://roundup.sourceforge.net/ .

I Second that. Extremely easy to set up and comes with quite reasonable default configuration.

When I have a choice (not very often when working with a company) I use FogBugz. It's a bit pricey compared to FREE, but now that they have a hosted version, it's great if you need to track bugs with a team.

The simplicity and approach of FogBugz is fantastic. Really worth a look if you have the cash to afford it. That being said - they do have provide it for free if you only need 2 accounts. See: http://discuss.joelonsoftware.com/default.asp?biz.5.482288

Joel, we know it's you.

I use a heavily modified version of Case Tracker, a group of addon modules for the Drupal CMS. It's similar to other helpdesks (it's actually a fork of the project and project release modules that are used at drupal.org) and it's being extended by a student during this year's Google Summer of Code.

Since Case Tracker runs in Drupal it's just one feature of an entire suite. I have all the features I need, from web-to-email, email-to-web (posting by email or phone), XML-RPC, a full range of access controls, wiki functionality, RSS feeds, etc.

Mantis is good, and it's fairly similar to Bugzilla (though better), so the transition should be pretty smooth. It was also a breeze to set up.

TRAC's my current favorite.

Too all the people using comments in the code and the like, that's very good when you're a 1-2 person team, but when you (hopefully) have more coders, possibly QA people and (god forbid) customers who complain about stuff that doesn't work well, you'd better switch to something that's more manageable.

I've used trac and mantis. Trac is kinda a pain to set up. Mantis is easy to set up, but very ugly.

I use //TODO: in my Visual Studio stuff. VS will find them for you automatically, I don't even have to grep for them.

I also try to write code so small and simple that it approaches the complexity of "Hello World." That way, it's easy to find the bugs.

I like keeping things simple while we're still small, so right now we just use 37signals' basecamp's (http://www.basecamphq.com/) to do list. this will probably change in the future

If I'm just working alone: ToDoList by AbstractSpoon Software http://www.abstractspoon.com/

For small projects it's enough to manage all my tasks, including bugs.

Personal projects: a 'TODO' text file, 1 line per issue, open in the editor (emacs or Eclipse) for the project.

Group/open-source projects: JIRA, which was a nice step up from Sourceforge's built-in tracking.

http://16bugs.com/

I fix bugs before I need to track them.

Mantis. Not great, but good enough - for now. May replace it if our needs get more complex.

http://acunote.com Naturally :-)

checklists stored in emails, & the backs of credit-card-bill envelopes

A simple shared spreadsheet in Google Docs for small projects. Trac for some others.

Mantis. But I tend to think the pages are too long.

index cards

Notepad

Ick. I would never rely on so crude a tool as Notepad for my bug tracking. I use emacs (text-mode).

A whiteboard.

Unfuddle!

Reply on news.ycombinator.com