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?

  • 2
    Yes, no, I agree wit you, Git uses mailing lists:) What I was saying is that you're lumping it in with "some really big projects" and I was just thinking that if you do that you should give a bit more examples for those really big projects. Otherwise the question comes down to "Git uses mailing list, why is that?" in which case Jörg W Mittag's answer is better suited... – Shivan Dragon Mar 26 '13 at 12:36
  • 1
    Hrm, well I was under the impression that there were more... Debian uses a mail based system, albeit more complex than a mailing list. Ok, but the main point is 'what are the advantages of using a mailing list over a bug tracker?' Unless the answer is "there aren't any, git developers are just luddites". – naught101 Mar 26 '13 at 13:01
  • @naught101: why do you get blown away when you see that? Debian unstable can be installed and used without seeing any remote root exploit needing patching and without needing any reboot for six months easily. That's for the unstable version of Debian. I've got Debian servers locked down who reached 4-digits days of uptime (not a single remote root exploit requiring a reboot affecting my setup during that period). These guys may not be using the latest technology fad, but they're obviously doing things right. I'd give up web bug trackers for Debian stability anytime. – Cedric Martin Mar 29 '13 at 17:23
  • 2
    @CedricMartin: I know, I agree. Mailing list bug tracking clearly works adequately for some teams, but it still seems less easy than a bug tracker, to me. I've been thinking though, that for the core project developers, the difference may seem very small: they follow nearly everything that's going on anyway. But for new-comers, a mailing list is nearly impossible to grok, so no simple overview of project fitness can be had. A bug tracker lets new users/devs quickly figure out how a project is moving, and get an idea of which kind of improvements are considered important by the core team. – naught101 Mar 30 '13 at 12:49
  • Greg Kroah-Hartman has a take on this as it relates to the Linux Kernel as part of this discussion. In particular: "There is NO way the github/gerrit/gitorious model would work at all for the kernel. The scale at which we work is a totally different level than could be handled by those tools. ... There really is no other known way to handle 10000 patches every 2 months, in a stable release, with peer review, with over 3000 developers, other than what we do today." – naught101 Dec 10 '14 at 4:17

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):

4.7.2 --help

The standard --help option should output brief documentation for how to invoke the program, on standard output, then exit successfully. Other options and arguments should be ignored once this is seen, and the program should not perform its normal function.

Near the end of the ‘--help’ option’s output, please place lines giving the email address for bug reports, the package’s home page (normally ‘http://www.gnu.org/software/pkg’, and the general page for help using GNU programs. The format should be like this:

    Report bugs to: mailing-address
    pkg home page: <http://www.gnu.org/software/pkg/>
    General help using GNU software: <http://www.gnu.org/gethelp/>

It is ok to mention other appropriate mailing lists and web pages.

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

Report bugs to: mailing-address

Note above doesn't mean that projects shouldn't be using issue tracker internally. As explained in an excellent answer to related question,

Your bug tracker is for your convenience, not your customers'. If you can't be bothered to take their phone or email issue and enter it yourself, how do you think they feel?

You need to be able to enter issues and assign them manually to a client...

  • 3
    Great answer! Email is better known than issue trackers, and easier to understand (which is not to say everyone "gets" email :P ) – Andres F. Mar 26 '13 at 15:59
  • 20
    Also, that GNU advice is ancient, way older than the web and web-based issue trackers. – Ross Patterson Mar 27 '13 at 0:24
  • @RossPatterson I was thinking that. But it seems unlikely that it's older than the web, considering it contains a bunch of URLs... – naught101 Mar 30 '13 at 12:56
  • 6
    @gnat: A major part of that linked answer being so great is the "if it's easy for you, you can enter that sort of thing right there" part. That is key to many open source projects, as there is no funding for phone support. A mailing list is a turn-off for me as a bug-reporting user, as I don't want to have to sign up for responses. With a bug tracker, I can see that the issue I have is in the system, and can come back and search for it later, and see if it's been updated. This is difficult with a mailing list, unless there is a really good web-based list tracker, which often isn't the case. – naught101 Mar 30 '13 at 13:08
  • 1
    @naught101 It might not be older than the Web but it's definitely older than Web-based trackers – sakisk Oct 16 '13 at 14:11

With Git, in particular, there is a simple historic reason: Git was started by Linux hackers for Linux hackers, and it uses the same development model and tools as Linux itself does. Linux, however, is older than the WWW, so, when Linux was started there simply were no web-based issue trackers, because there was no web!

As a consequence, the Linux community has developed extremely efficient tools and workflows for dealing with bug reports and code reviews over email, and there was no reason for them to throw all of that work away and start from scratch when they started the Git project.

  • 3
    I thought that the WWW preceded Linux. Slightly. They were both very much done at about the same time and by different groups of people; it wasn't really until the mid '90s that either took off. – Donal Fellows Mar 26 '13 at 11:17
  • 6
    Ok, but the linux kernel now has a bug tracker: bugzilla.kernel.org. Clearly that's not such a large barrier. – naught101 Mar 26 '13 at 11:22
  • 6
    -1 Git is seriously younger than the web. Vintage 2005. There were plenty of issue trackers at the time, including of course Bugzilla. Linus just doesn't like issue trackers, and his word is law in that environment. – Ross Patterson Mar 27 '13 at 0:26
  • 6
    @RossPatterson - He said Linux was older than the web, not Git. I don't think your comment justifies a down vote, since you basically repeated what he said. – beatgammit Mar 27 '13 at 8:58
  • 2
    @tjameson On hindsight, you're right. Back to neutral. – Ross Patterson Mar 27 '13 at 11:13

For Git:

There are several discussions on the mailing list where people propose to use some kind of bug tracker. These initiatives seem all to have fizzled, so the reason Git does not uses a bug tracker is probably simply that most contributors do not find it useful.

In a post to the mailing list, Junio C Hamano (Git's maintainer) summed up why he feels a bug tracker is not very useful. I don't want to include the whole post (it's quite long), but it boils down to:

  • If you are only looking for information on solved problems, searching the list archives works just as well as searching a bug tracker.
  • If you report a genuine bug, and people want to take care of it, the list also works well.
  • If no one is interested in working on a problem, it will fall through the cracks, even in a bug tracker.
  • A bug tracker would be one more system that needs to be maintained, checked for new bugs regularly, have fixed bugs closed etc., in short, extra work for little benefit.
  • 4
    Good answer, but I would argue that your 3rd point is a major disadvantage of email: If a bug is hard to fix and the current devs are lazy it gets significantly more buried than an entry in an issue tracker. This could mean certain bugs are never fixed, simply because people don't know their there – TheLQ Mar 28 '13 at 8:32
  • 1
    @TheLQ: True. However, apparently that's a risk some projects are willing to take. And to be fair, git is a fairly solid piece of software, even without a bug tracker. – sleske Apr 22 '13 at 8:47
  • 1
    @TheLQ: Wouldn't a simple web page mentioning all known bugs (And their related threads) resolve that? Something similar to this except that links point to archive threads. – Hello World Sep 17 '14 at 6:21
  • 1
    @HelloWorld: Well, that would be a (simple) issue tracker. And just like an issue tracker, someone would have to manage it... – sleske Sep 17 '14 at 7:32

Debian does use a bug tracker, its default interface is email. And it is convenient. Lucas Nussbaum, current Debian Project Leader, posted a few days ago:

debbugs is the piece of software behind the Debian Bugs Tracking System (BTS). It is also used by the GNU project. Despite often being perceived as old-style, it features several unique features, such as the tracking of the status of bugs in each version and branch of a package ), or the ability to perform all interactions via email, making it very easy to work offline or in poorly-connected environments.

The last part is a killer feature here - just queue those reports in your local mail queue until you got off the plane!

  • Keeps 9 year olds out.
  • No need to create a separate account for each forum.
  • [minor]Consistent user experience across different mailing lists and a zero learning curve when subscribing to a new list.
  • Works offline. you could connect to the Internet and download a batch of mails, then go hiking, write your replies while enjoying mother nature and send them later.
  • Allows mail encrypting and/or signing via GPG.
  • Decentralized - If the forum crashes, you'd still have a copy, it's also tamper resistant, an evil moderator/hacker cannot easily tamper with what you've said. No one can undo history.
  • Allows filters, folders, and all the advanced organizational features of an Email client.
  • "Push notifications" - you can leave your Email client open and get notifications of new replies.
  • One place to rule them all - no need to jump between different sites.
  • Immune to all the security vulnerabilities involving the web (html/javascript/injections, etc)
  • No bloat - No badges, fancy moving signatures, ads, web beacons, javascript bloat. It's all simple and to the point - discussion.
  • Less server burden than a LAMP setup.

One disadvantage of mailing lists that comes to mind is that forums are dividable into categories and subcategories while mailing lists are not. This can be emulated by dividing a mailing list into several mailing lists, and then users can use the appropriate filters to put each message with its corresponding folder (Each folder being a category). In web forums, this is automatic.

  • why do people insist on creating web based versions to track issues (BTW this question is not about everything) is discussed in another question: Getting users to write decent and useful bug reports "User-editable online bug reports are the most efficient way to teach users improve..." – gnat Sep 17 '14 at 6:51
  • Thank you. But does this justify a downvote? The main topic of this answer is the advantages of a ML, and it answers the original question rather well. I have removed the "web forums" rant. – Hello World Sep 17 '14 at 7:01
  • 2
    The disadvantage mentioned in this answer actually fundamentally precludes me from sticking with most dev mail lists. They send through everything, so after reporting a bug I usually unsubscribe a mere two weeks later. Bugtrackers nicely solve this problem by letting me subscribe to specific bug reports. – Roman Starkov May 10 '15 at 0:28
  • 5
    Correction: keeps 25 year olds out. Only recently did I learn how those mailing lists things work to contribute to some real projects. And I hate it!! – Ciro Santilli 新疆改造中心 六四事件 法轮功 Jul 31 '15 at 11:16
  • 2
    "No need to create a separate account for each forum." - often to prevent spam you need to sign up for list. But that subscribes to all emails. So you need to subscribe AND opt out from 'spam' AND add request to keep you in CC or TO. Compared with a bugzilla it's much more to do. – Maciej Piechotka Oct 19 '17 at 18:44

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.