Triaging bugs of GNU Emacs

I have been using Emacs for more than 6 months. mbuf and me were discussing about some way to package Emacs as container image so that we can run that image to test things, triage bugs for a particular version etc. Before getting started with that, he wanted me to have idea about existing bugs of Emacs and how to triage them, so that I get better idea of whole work flow. I agreed that it would be the best way to get started and contribute back to the tool, which is part of my daily life. In this blog post I will be talking about reporting bugs, searching existing bugs, triaging them and also how to build Emacs from source.

What is bug triaging?

Bug tracking system is an important part of a project. This is the place where users and maintainers of the project report the issues faced by them. Bug tracking systems are also used for discussing new ideas and features related to the project. When the project has a large user base, managing and tagging bugs becomes crucial part of the work flow. If bug reports are tagged correctly, it becomes easy for maintainers to focus on critical bugs and features. Bug triaging is the process of verifying the bugs reported by other users. This includes following things:

1. Verifying the bugs reported by users and then tagging them as verified/confirmed
2. Asking for more clarification to the reporter of the bug if required
3. Setting the severity level of the bug if possible
4. Marking the bug as solved, if it has been solved in a particular version/release of the project
5. If the bug occurs only in a specific release, then marking the bug report accordingly

The above tasks can include building or deploying the project from source code.

More about Bug tracking system on Wikipedia.

GNU Bug Tracker system

Let’s see how Emacs’ bug tracking system works. Emacs uses GNU Bug Tracker which is available at https://debbugs.gnu.org. It’s an instance of Debbugs. This Bug tracker provides a web interface and uses mailing list as an interface to post comments on bug reports. You can find the list of packages, which use this tracker, here. Documentation about the bug tracking system.

Web user interface

Web UI shows a list of all the reported bugs for a particular package. It provides options to filter these bug reports. On every page you can see different categories like outstanding, resolved, patch available, minor etc. These categories are based on the metadata associated with the bug reports. It’s possible to search based on words in title of bugs, tags, categories, submitter, owner etc.

List of recently created 100 bug reports for Emacs: GNU bug report logs: bugs in package emacs

Apart from web UI, there are two mail servers to whom you can talk to. Let’s take a look at each of them.

request server

This mail server can be used to get details about existing bug reports. When you send mail to request at debbugs.gnu.org with supported commands, it sends details in plain text. It interprets the message as one command per line. Response is generated according to the given commands.

For example to get details about bug with number #33973 you can send a mail like this

Subject:   details about bug #33973
To:        request [at] debbugs.gnu.org
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
send 33973

Read Introduction to the bug system request server for more details and commands of request server.

control server

The control mail server is used to manipulate bug reports. Operations like classifying bugs, tagging them with labels are done using this server. It’s the same request server program running at different address and having additional commands. Address is control at debbugs.gnu.org. We will be using this server while triaging bugs.

Take a look at Introduction to the bug control and manipulation mailserver for list of all the available commands.

Triaging Emacs bug reports

Make sure you have subscribed to the bug-gnu-emacs mailing list. This will keep you updated with discussions on new bug reports.

Let’s take a look at bug report #35815. Details like bug number, title, package name (which is emacs in our case) are at the top. After that we can see that only Severity and version of Emacs is mentioned. This bug has no tags (at the time of writing this post), as a result of this it will appear as unclassified minor bug on the main page.

Before selecting a bug to triage, make sure it’s from an unclassified section. Read the details provided by reporter carefully. Then try to reproduce same bug on version mentioned by them. Also try the same steps on latest build from master branch. If the reported version is greater than latest release of Emacs, then you will need to try the steps on latest build from master. Post your findings and or questions by replying to that bug report. If the bug gets reproduced then tag it as confirmed. Sometimes you may need ask few questions to the reporter in order to get more clarity about the issue.

Replying to a bug report

To reply a bug with number 12345, send mail to 12345 at debbugs.gnu.org.

• Don’t top post and follow mailing list etiquette
• Make sure you add <number> at debbugs.gnu.org in To or CC field while replying to a mail received on mailing list
• Never keep <number> at debbugs.gnu.org in BCC while replying. It will omit bug tracker mail when someone replies to our mail

You can take reference of this reply for #34268.

Tagging bug reports

In order to tag bug reports, you can send mail to control server with commands like tags. The mail mentioned below will tag the bug #33973 as confirmed and mark it as found in version 27.0.50.

To: control [at] debbugs.gnu.org
Subject: control message for bug #33973
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
tags 33973 confirmed
found 33973 27.0.50

Web UI will show messages like this, after the operation is performed.

View the full message.

Read more on Severity levels and Tags for bug reports.

Examples

Here are some other examples which will give more clarity about working with bug reports.

• Asking for more information to the reporter: Message #8 on #35119
• A report which is merged with other bug reports: #33973
• Adding explanation to mail while sending commands to control server: Message #15 on #33979. (Anything after quit is treated as a comment by both request and control servers)

Read more about Followup messages.

Build Emacs from source

GNU Emacs is written in C and Elisp. The source code is hosted on savannah.gnu.org. Following steps are for building Emacs on Fedora (Tested on Fedora 30). Process should be similar on other distributions.

Prerequisites

1. Clone the source code from git repository

$ git clone https://git.savannah.gnu.org/git/emacs.git
$ cd emacs

2. Install build dependencies

This will install all the packages which are required to build Emacs.

$ sudo dnf install autoconf
$ sudo dnf builddep emacs

Read more about builddep.

Build the binary

Once you have completed the steps from prerequisites, whenever you want to build Emacs run

$ make

Depending on your machine, it can take 10 to 25 minutes. emacs binary will be saved in src/emacs in the project root directory. To launch Emacs execute

$ ./src/emacs

To build different version switch to respective branch or tag i.e. emacs-26 and run make again. (The branch emacs-26 contains code for next 26.x release, while the tag emacs-26.1 contains code for 26.1)

# Checkout branch emacs-26
$ git checkout -b emacs-26 origin/emacs-26

Switching to a specific tag

# Fetch the tags and checkout emacs-26.1
$ git fetch --tags
$ git checkout tags/emacs-26.1

Read more about checking out branches and tags.

For more information about this process, see INSTALL and INSTALL.REPO files.

Reporting bugs

• https://www.emacswiki.org/emacs/EmacsBugs
• https://debbugs.gnu.org/Reporting.html