The benefits of oops reports and test driven development

Today I fixed a bug where users could not link a project series to package in an older Ubuntu series. I reported the bug when working with Javier to clean up the duplicate glade projects registered in Launchpad. We both got oopses when we tried to fix the packaging links from the project’s packaging form. We fix them using the distro series packaging form.

I assumed the project version of the form was ignoring the submitted series; it always uses the current Ubuntu series. I wrote my test using the same situation that I experienced, and I expected a failure when I ran the test. I did get a failure, but it was not about the current Ubuntu development series. It was a database IntegrityError. I know that error!

Every morning, I read the oops reports from the many Launchpad process. Every exception and timeout in Launchpad is collated into a a daily report for the engineers to read. I report bugs for each problem that relates to the registry application. Most bugs I report from oopses contain enough information to fix the problem within a week. Last week I saw an IntegrityError in the oopses, but I could not reproduce it. So while I scheduled the bug to be fixed in the 10.04 release, I could not write a test it to fix it. I could not see that the IntegrityError was about a series different from the one the user submitted.

I got lucky today. The test setup creates all the objects in play. My bug from yesterday, and the bug from last week were the same bug that manifests itself in two ways depending on the state of the package in the current series. I marked the IntegrityError bug to be a duplicate of the bug I was fixing. The form was indeed ignoring the submitted distro series; it was a one line fix. If I had written the fix before the test, I would still be investigating the oops without a clue.