Bug tracker for any decent sized project seem like a bit of a no-brainer to me – it makes it really easy to organise hundreds or thousands issues, without issues colliding or getting mixed up.
So when I see some really big projects, like Git, using a mailing list as the main method of coordinating maintenance and development, I get a bit blown away. Examples:
-
Git – Community page:
…Bug reports should be sent to this mailing list.
-
Debian bug tracking system, per Wikipedia:
…Its unique feature is that it doesn't have any form of web-interface to edit bug reports – all modification is done through email.
Many modern bug trackers have very good integration with email (you can receive comments or notifications about bugs you're watching, or that get assigned to you), as well as to version control systems (commits can be marked as resolving an issue, etc.). Much of this would have to be done manually with a mailing list, and you get tons of emails about bugs you're not interested in.
So what are the main advantages of a mailing list over a web-based bug tracker? Why do some big projects only use a mailing list?
Best Answer
The preference you observe looks like a natural consequence of recommendation clearly stated in GNU Coding Standards. It suggests to report bugs by email, as you can see in below quote (I marked bold the part that directly addresses your observations):
Above preference, in turn, reflects universal acceptance of email as a form of electronic communication. Any user reading
--help
message like suggested above is supposed to easily understand what to do if they see a bug - mailing is easy.Issue tracker might be (and I think is) better for a developer working in the project, but for a wider audience it would be harder to present and explain how to use it, especially taking into account wide variety and differences between different issue tracking systems.
One project can use Bugzilla, another will stick with JIRA, third with... GNATS, etc etc, etc. There's just no way to present all this "zoo" in a way that would be as standard and uniform as
Note above doesn't mean that projects shouldn't be using issue tracker internally. As explained in an excellent answer to related question,