74

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?

gnat
  • 20,543
  • 29
  • 115
  • 306
naught101
  • 1,248

5 Answers5

48

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...

Community
  • 1
gnat
  • 20,543
  • 29
  • 115
  • 306
33

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.

Jörg W Mittag
  • 104,619
19

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.
sleske
  • 10,280
8

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!

gnat
  • 20,543
  • 29
  • 115
  • 306
Dominik George
  • 180
  • 1
  • 4
5
  • 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.

Hello World
  • 194