Koha bugs workflow

As the Koha project has grown our workflow has evolved to meet the demands of a wider pool of developers. We’re better today at collaborating thanks to Git, our version control system. We’re better at communicating with each other through the Koha wiki and Koha’s Bugzilla database. It has helped a lot that we’ve worked to establish some consistent steps to handle both bugs and new features.

Filing a bug report

When you’ve discovered a bug in Koha the first stop is Bugzilla. Bugzilla is an open-source bug-tracking system developed by the folks who brought you Mozilla Firefox. We have our own installation of Bugzilla, generously hosted on a donated server. Anyone can file a bug, whether you’re a Koha developer or a Koha user.

If you find a bug the first step is to report it. Even a developer intending to immediately fix a bug should file a bug report. Doing so will mean others won’t duplicate your efforts in isolating the bug. When you file a bug report Bugzilla will offer to assign the bug by default to the person who has volunteered for bugs of that category. For instance, I am assigned by default any OPAC bugs. That doesn’t mean I’ll be able to fix them all, but I’m notified of each one and I can always reassign them if I find they’re beyond my capabilities.

You can also assign the bug a “severity” setting. If you’re not sure, use the “normal” severity for bugs, and “enhancement” if you’re asking for a feature to be added. There are brief descriptions of Bugzilla’s severity levels for review if you’re not sure how to classify something.

There are much more detailed bug reporting guidelines on the Koha Wiki.

Now the bug is in the database. With any luck, anyone else who discovers the same bug will search Bugzilla first before reporting it. If you find an existing report for a bug you’re experiencing, review it to make sure all the pertinent details are there. Feel free to leave comments expressing in specific terms how the bug is affecting your library’s workflow. Understanding the impact of a bug might help others prioritize efforts to fix it.

What happens to your bug?

What happens to a bug report after it gets filed? If the report was filed without any plans to address it (that is, if you’re not a developer filing the bug, with plans to fix it right away), nothing may happen for a while. Ideally the default assignee of the bug will review it and take some action if necessary: Correcting the bug’s severity, asking clarifying questions, reassigning if necessary. Unfortunately there is no guarantee that anything will happen with a bug report once it is filed. If no one else is affected by (or cares about) the bug, there won’t be any incentive to fix it. Developers are often working on projects assigned to them by their customers, and if they’re not getting paid to fix a particular bug they may not choose to work on it.

Your bug finds acceptance

If someone decides to work on your bug report, the first thing they should do is “accept” the bug in Bugzilla. If the bug isn’t already assigned to them, they edit the bug to assign it to themselves and update the status of the bug from “New,” the default for all new bugs, to “Assigned.” This tells anyone browsing Bugzilla that someone has agreed to work on the bug. Careful use of bug assignment and the use of the “assigned” status helps prevent duplication of effort: I won’t spend time working on a bug if I think someone else is actively working on it already.

If the developer who took on your bug discovers a fix for it, the next step is to submit a patch. A patch is a special file which can be understood by our version control system. Just as a patch on a piece of clothing is just a small piece of cloth to fix a hole, a software patch is just a small piece of code which can be applied to a whole file (or even multiple files). The patch includes instructions to add certain lines or remove certain lines of code.

The developer who has come up with a patch will do two things with it: First, the patch gets submitted to a special Koha mailing list for all Koha patches. Koha’s Release Manager monitors this list and evaluates each patch and evaluates it for inclusion in the next version of Koha. The second place the patch will go is into the Bugzilla bug report. The developer will attach the patch to the bug report so that others can see that a patch was submitted and maybe review the patch themselves. Since the patch file is easily understood by the Git version control system, anyone running an installation of Koha from a Git repository can apply patches and test bug fixes. A bug in Bugzilla which has has a patch filed for it will be marked with a special priority, “PATCH-sent.”

Your bug found acceptance, but what about the patch?

Galen Charlton, the Koha 3.2 Release Manager, has the task of evaluating each patch that is submitted for inclusion in 3.2. He reviews patches, tests them, and approves them if he finds them worthwhile. If a patch refers to a specific bug report, Galen will usually also update the bug report with a note that the patch was “pushed.” If a patch doesn’t seem to work, or if it includes mistakes which should be corrected before inclusion he will let the patch submitter know so they can rework the patch.

Right now we’re getting so close to the release of 3.2 that we’re under both a “feature freeze” and a “string freeze.” A feature freeze means that no new features are being accepted for inclusion in 3.2: only bug-fixes. Rejecting new features at this point in the process reduces the possibility that major new bugs will be introduced. The “string freeze” means that patches submitted for inclusion in 3.2 should no include changes to any text in the interface. These text strings must be painstakingly translated. The Koha translation-tracking system Pootle lists 63 different languages which have at least begun to have translations done. Putting on a string freeze means that translators preparing for the release of 3.2 will have a fixed target.

The patch for your bug made the cut. It’s going into 3.2!

You reported the bug, so your job isn’t done yet. It’s time to test the fix. Update your test installation and try to follow the same steps that led to the bug before. Is the bug still there, or is something still left undone? Then update the bug and explain what you found.

On the other hand, if you find the bug has been fixed then you can mark it as such in Bugzilla. Change the status of the bug from “Assigned” to “Resolved (Fixed).”

Congratulations, and welcome to the team.

6 thoughts on “Koha bugs workflow

  1. Daniel G

    Thanks, Owen, for this excellent post! I found it very helpful, especially in light of the recent discussion on the Koha list about the process of integrating the various forks of Koha.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *