Bug tracking system recommendation

[elektrophyte]

My organization is looking for a Web-based bug tracking system that can
run on Linux and uses either MySQL or Oracle. It doesn't matter too
much what language it's written in, though either Java or something
that doesn't require an interpreter would be preferred over Perl or
PHP. We're looking for something that can be installed easily without a
long period of struggling to get a lot of interdependant components
working together. We don't have a lot of extra time available for a
long process of installing and / or maintaining the system. On the
other hand, we definitely don't want a hosted solution. We prefer to
keep it in-house.

Any recommendations would be greatly appreciated. I know that a lot of
people use Bugzilla, but my sense is that it's more appropriate for
large shops and technically-skilled users. We just have a few people
who will be using the system. Some of the people reporting bugs will
not be engineers and would probably be intimidated by a very complex
UI.

Thanks in advance for any help with this question.

E

 

[Oliver Wong]

My organization is looking for a Web-based bug tracking system that can
run on Linux and uses either MySQL or Oracle. It doesn't matter too
much what language it's written in, though either Java or something
that doesn't require an interpreter would be preferred over Perl or
PHP.

It might be worth clarifying the above statement; the reasons one has
for avoiding an interpreter is usually also reasons to avoid Java.

We're looking for something that can be installed easily without a
long period of struggling to get a lot of interdependant components
working together. We don't have a lot of extra time available for a
long process of installing and / or maintaining the system. On the
other hand, we definitely don't want a hosted solution. We prefer to
keep it in-house.

In my experience, setting up Apache with JSP was a lot more troublesome
than setting up Apache with PHP and MySQL. YMMV.

Any recommendations would be greatly appreciated. I know that a lot of
people use Bugzilla, but my sense is that it's more appropriate for
large shops and technically-skilled users. We just have a few people
who will be using the system. Some of the people reporting bugs will
not be engineers and would probably be intimidated by a very complex
UI.

Assuming these non-engineers are employees of your shop, it doesn't seem
unreasonable to spend an hour or two as a "training" session to explain how
to fill out the bug report form on Bugzilla. Regardless of what software
you'll use, you'd probably get optimal use out of it if you do spend a few
hours training the non-engineers: they might not know how to write effective
bug reports! Make sure they're aware of the 3 basic pieces of information
that make a bug report useful:

1) How do you reproduce the bug?
2) What did you expect to see?
3) What did you see instead?

Without some informal training (reading the above list may be considered
sufficient "informal training"), the bug reporters might end up just
submitting hard to understand bug reports anyway.

- Oliver

 

[Roedy Green]

My organization is looking for a Web-based bug tracking system that can
run on Linux and uses either MySQL or Oracle. It doesn't matter too
much what language it's written in, though either Java or something
that doesn't require an interpreter would be preferred over Perl or
PHP. We're looking for something that can be installed easily without a
long period of struggling to get a lot of interdependant components
working together. We don't have a lot of extra time available for a
long process of installing and / or maintaining the system. On the
other hand, we definitely don't want a hosted solution. We prefer to
keep it in-house.

check out Jira. It is not just bugs, but the entire project.
see http://mindprod.com/jgloss/jira.html

 

[Roedy Green]

It might be worth clarifying the above statement; the reasons one has
for avoiding an interpreter is usually also reasons to avoid Java.

Java is not interpreted on the desktop, only in handhelds. It is
JITed, natively statically complied, or hotspotted.

See http://mindprod.com/jgloss/compiler.html

 

[Roedy Green]

Assuming these non-engineers are employees of your shop, it doesn't seem
unreasonable to spend an hour or two as a "training" session to explain how
to fill out the bug report form on Bugzilla. Regardless of what software
you'll use, you'd probably get optimal use out of it if you do spend a few
hours training the non-engineers: they might not know how to write effective
bug reports! Make sure they're aware of the 3 basic pieces of information
that make a bug report useful:

I wonder if it might pay developers to have a log feature to help in
tracking bugs. It would take a snapshot of the registry and data files
and bundle them up in a zip, then log keystrokes and mouse clicks and
moves (possibly abbreviating moves). Then the vendor would have an a
way of knowing exactly what the user did and where he started from.
Maybe there might be a way to get a screen snap even after the app has
crashed.

In the old days of DOS/Abundance I did a screen snap, stack trace,
crucial application info -- e.g. what variable it was working on in
what array in what file and error message to printer (or virtual
printer) so that they would have something concrete to send me without
any work on their part to copy. Now we have high speed Internet, we
should be exploiting that rather than relying on users to tell us what
happened.

The other tool I have not seen used is something like PCAnywhere where
the vendor and customer watch simultaneously as the customer causes
the problem.

I have found vendors much more willing to take action if accompanied
by a screen shot. That is much more compelling proof there is a
problem than any number of words.

This brings up one of my pet peeves, error message filled with hex and
other gibberish you cannot copy/paste to give to the vendor. Copying
this to paper and transcribing is time consuming and introduces
errors.

 

[Neill]

My organization is looking for a Web-based bug tracking system that can
run on Linux and uses either MySQL or Oracle. It doesn't matter too
much what language it's written in, though either Java or something
that doesn't require an interpreter would be preferred over Perl or
PHP. We're looking for something that can be installed easily without a
long period of struggling to get a lot of interdependant components
working together. We don't have a lot of extra time available for a
long process of installing and / or maintaining the system. On the
other hand, we definitely don't want a hosted solution. We prefer to
keep it in-house.

Any recommendations would be greatly appreciated. I know that a lot of
people use Bugzilla, but my sense is that it's more appropriate for
large shops and technically-skilled users. We just have a few people
who will be using the system. Some of the people reporting bugs will
not be engineers and would probably be intimidated by a very complex
UI.

Thanks in advance for any help with this question.

E

Take a look a FogBugz at http://www.fogcreek.com/

I've been reading Joel for a long time, and like his views on software
development.

 

[Andrew McDonagh]

My organization is looking for a Web-based bug tracking system that can
run on Linux and uses either MySQL or Oracle. It doesn't matter too
much what language it's written in, though either Java or something
that doesn't require an interpreter would be preferred over Perl or
PHP. We're looking for something that can be installed easily without a
long period of struggling to get a lot of interdependant components
working together. We don't have a lot of extra time available for a
long process of installing and / or maintaining the system. On the
other hand, we definitely don't want a hosted solution. We prefer to
keep it in-house.

Any recommendations would be greatly appreciated. I know that a lot of
people use Bugzilla, but my sense is that it's more appropriate for
large shops and technically-skilled users. We just have a few people
who will be using the system. Some of the people reporting bugs will
not be engineers and would probably be intimidated by a very complex
UI.

Thanks in advance for any help with this question.

E

go with JIRA - its great.

http://www.atlassian.com/software/jira/

 

[Virgil Green]

My organization is looking for a Web-based bug tracking system that
can run on Linux and uses either MySQL or Oracle. It doesn't matter
too much what language it's written in, though either Java or
something that doesn't require an interpreter would be preferred over
Perl or PHP. We're looking for something that can be installed easily
without a long period of struggling to get a lot of interdependant
components working together. We don't have a lot of extra time
available for a long process of installing and / or maintaining the
system. On the other hand, we definitely don't want a hosted
solution. We prefer to keep it in-house.

Any recommendations would be greatly appreciated. I know that a lot of
people use Bugzilla, but my sense is that it's more appropriate for
large shops and technically-skilled users. We just have a few people
who will be using the system. Some of the people reporting bugs will
not be engineers and would probably be intimidated by a very complex
UI.

Thanks in advance for any help with this question.

E

Take a look at eventum. Developed and used by the mySQL group.

http://dev.mysql.com/downloads/other/eventum/

It, however, PHP-based.

Also take a look at Mantis

http://www.mantisbt.org/

It is also PHP-based. However, both of these are free.

 

[Chris Smith]

In my experience, setting up Apache with JSP was a lot more troublesome
than setting up Apache with PHP and MySQL. YMMV.

Setting up Apache with JSP is undoubtedly more troublesome than setting
up Apache with PHP. So why in the world would you set up Apache? This
is just a bug tracking system, after all. I find that setting up Tomcat
(and configuring it to speak HTTP directly) is actually easier than
setting up Apache alone.

On the other hand, if you're looking to handle extreme levels of mostly-
static traffic or need something that Tomcat can't do easily (for
example, URL rewriting or running a PHP app beside the bug tracking
system), then Apache would probably be needed.

Assuming these non-engineers are employees of your shop, it doesn't seem
unreasonable to spend an hour or two as a "training" session to explain how
to fill out the bug report form on Bugzilla.

One good reason might be that the bug reporting form in BugZilla assumes
a lot of procedural stuff that smaller vendors simply won't use. I have
often found myself in search of a smaller bug tracking system instead of
handling the beast that is BugZilla.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Zsolt Koppany]

Check CodeBeamer, it is integrated wit version control systems such as cvs,
subversion, vss, pvcs etc.

http://intland.com/products/codebeamer.html

Zsolt

 

[Oliver Wong]

Java is not interpreted on the desktop, only in handhelds. It is
JITed, natively statically complied, or hotspotted.

Relunctant agreement (I agree with the general gist of what you say,
though there are some details which make your statement not true in all
circumstances). But I wasn't worried about whether or not Java was
interpreted; I was just saying if one of your requirements is "no
interpreted languages", then there's probably a root reason behind that
requirement, and that reason might equally apply to Java as well.

One reason to avoid interpreters is that you don't want to install extra
software on your production machine, which may be a valid reason to avoid
Java, for example.

- Oliver

 

[Oliver Wong]

One good reason might be that the bug reporting form in BugZilla assumes
a lot of procedural stuff that smaller vendors simply won't use. I have
often found myself in search of a smaller bug tracking system instead of
handling the beast that is BugZilla.

Good point, and this is a reason I've been looking for alternatives to
BugZilla as well. However, the two hacks I've encountered (or editing the
source code to just comment out the displaying of such fields), or to inform
the testers to just ignore those fields, have been "good enough" for most
environments I've worked in.

Still, if you find a smaller, simpler bug tracker, let us know.

- Oliver

 

[Oliver Wong]

I wonder if it might pay developers to have a log feature to help in
tracking bugs. It would take a snapshot of the registry and data files
and bundle them up in a zip, then log keystrokes and mouse clicks and
moves (possibly abbreviating moves). Then the vendor would have an a
way of knowing exactly what the user did and where he started from.
Maybe there might be a way to get a screen snap even after the app has
crashed.

While this may be a good idea for software "in the wild", if you have
internal testers whom you are paying, it might be nice to actually have
those testers go through the effort of actually trying to narrow down and
determine what the *MINIMAL* sequence of steps are required to reproduce the
bug.

The other tool I have not seen used is something like PCAnywhere where
the vendor and customer watch simultaneously as the customer causes
the problem.

I believe this is (relatively) commonly done when supporting the
computer in general, rather than a particular program. That is, something
goes wrong with a user's computer, and rather than contacting a particular
software vendor, the user just contacts a general help desk who will watch
the user replicate the problem and then solve it, or inform the user of who
she needs to contact to have the problem solved.

This brings up one of my pet peeves, error message filled with hex and
other gibberish you cannot copy/paste to give to the vendor. Copying
this to paper and transcribing is time consuming and introduces
errors.

The advantage of a hexadecimal number is that it is typically some sort
of identificiation number that can pinpoint the exact error that occured,
and being a non-fluffy format, can probably be typed with less effort than
an full English message.

Of course, it sucks if this hexademical number happens to be several
hundred hex-digits long.

- Oliver