I'm pretty fond of Mantis, as mentioned, but I've seen effective usage of both github/lab issues with good usage of labels and a little bit automation. Since much more automation is required to integrate even a lean bugtracker into your source, I cannot recommend using a separate bugtracker unless you have an extremely good reason for it.
Factor in that ease of reporting both for you and for your users should be in the top #3 reasons for using a specific bug tracker.
Bugzilla IMHO only works as an internal-only tracker for developers or testers directly involved with the code and decent overview/discipline of the triaging process.
I use Bugzilla to track both bugs and other wrok-to-be-done. When I close an issue in BZ, I also add a reference to which version control check-in addressed it.
Using Bugzilla as a general issue tracker makes it easier to prioritize both bug fixing and feature changes, as well as keeping a database of what work I've done, and when.
For just straight-up bug tracking, Bugzilla isn't all that bad. Though we do some fun interactions where we put SCM commit messages on a bug as a comment, then have a Greasemonkey script to pretty format those commit comments on bugs.
For feature tracking of timeline type of views, Bugzilla is fairly useless, but for just doing bugs, it does a good job.
> If you have to sign up to file a bug, the bug is going to be important to you.
This. That's the reason why bugzillas rock! Visit the GNOME bugzilla, Red Hat bugzilla and even Mozilla bugzilla for instance and have a look. Its always organized, focused and in problem-solving mode. Unlike Github issues, people don't stampede there to just say "Hi" or "How may I use this thingy?", they bring their actual problems in all seriousness (because they have to register, verify their emails and then login just for the sake of posting an issue)
I run an open source project and I typically use github to track bugs, but I'm reluctant to have a dedicated bugzilla (or whatever) for the project as ~90% of bug reports are not bugs in my library, but rather installations issues or bugs in people's own code. I'm not saying my code doesn't have bugs(!) but what are often reported are bugs are nothing of the sort.
It would be nice to have a bug tracker, but I just don't believe it would be used to track only bugs and would thus take up time which I'd rather use for developing the software.
If you contact Red Hat support you'll get immediate help. If you have a support contract you shouldn't be filing bugs in Bugzilla, since the support team will do that for you, and chase the developers to get things fixed. Your support contract will make all this clear.
For anyone looking on and thinking of following this advice, please don't treat Bugzilla like GitHub, where advocacy and general discussion is the norm. Bugzilla is for code reviews and for people who are otherwise working together so they can coordinate and get things done. It's not an open solicitation for people to jump in and voice their opinions about general project directions, etc. If you do try to use Bugzilla the wrong way, you'll likely be warned about generating too much noise and possibly banned.
Please do continue using social platforms like blogs, comment sites like this one, etc. for posting opinion pieces and weighing in. That's where general commentary belongs, and it'll be much more effective to boot, if you're interested in getting people's attention or changing minds.
I think they also have a Bugzilla, and hopefully they'll move away from that too. (Not because bugzilla is bad, it's just oldschool and makes no sense to keep issue tracking separate.)
Maybe I'm outing myself in terms of age, but not only do I pretty much agree with jwz here, but I'm happy to say that we[1] use Bugzilla[2] for our bug tracker[3] for all our open source projects.
Of course, you might argue that it's easy for us, as we don't have a ton of users opening gazillions of bugs. It is a fair point, that simply triaging bug reports can become a big time sink in larger projects. Makes me wonder if some technological tooling (eg, better "dupe" detectors, etc.) could help manage the problem.
reply