Launchpad bug titles are everywhere!

A while back, I wrote about smart autolinkifying in bugs. Last week, at the urging of Brian Murray, I built on top of the work that I’d already done. This time, it grabs all the bug links and sends to the linkchecker and, in addition to the set of invalid bugs, it also returns a set of valid bugs with bug titles! The after effect is a ‘bug 1245’ link in the body of Launchpad like in bug tracker, merge proposals, etc, where bug 1245 is a valid bug number will have its ‘title’ attribute set to the bug title.

Valid bugs have the 'title' attribute set as bug title and it shows up as a tooltip

Some new improvements to Launchpad

I’ve been hacking on Launchpad for a while now and I’d like to announce some of the new things I’ve added. The first 2 are in production now. The last two, however, will need a few more days to get into production.

Smart autolinkifying in bugs

As evident from the screenshot, it greys out the bug if the bug does not exit (or is private). I wrote in detail about fixing this earlier.

Invalid bugs are greyed out

UTC offset along with timezone

We now go the extra mile and display the UTC offset as well to help in some play plan out meetings, etc.

Timezone also shows UTC offset

Edit sprite for attachments

Long time frustration of mine. The edit URL for attachments is in a portlet on the right side, not easy to spot. Once this fix rolls out, however, it will be much more friendlier.

Edit sprite for attachments

Better blueprints validation

Earlier, I’d just get a ‘… is already registered by another blueprint’, this fix, once rolled out, helps ease out and find that blueprint.

Blueprint validation

To repeat again, the last two fixes are not in production as of me writing this post. Perhaps by next week or the week after, it should be.

Another Launchpad Bug Fixed!

On Tuesday, I managed to land a fix for another Launchpad bug. This one probably was my first non-trivial bug fix and also older than any other bug I’ve attempted (4-digit bug!)

Earlier, during page load, Launchpad would take each bug, search if its, valid, get the title, and show tooltips. This feature was removed to reduce page load times and timeouts. Instead, anything that matches the bug pattern gets linked whether the bug is valid or not. Obviously, less friendly, but much faster. One of the days, there was a general complaint about this in #launchpad-dev and Ian Booth mentioned that its probably trivial to fix with the link checking bits he wrote for branches. I jumped in when I saw a chance to get mentored for a bug.

Fixing the bug involved, first adding a class to all the bug URLs, then grabbing all the URLs with that class and posting it as JSON to check-links internal API, which uses the search to verify valid/invalid bugs. Then, it returns a list of invalid bugs. Fixing this including writing python and JavaScript code; a first, for my fixes to Launchpad. I broke a gazillion tests with my fixes though. Twice, I submitted it to ec2 and failed thanks to b0rked tests. Finally, on third try, I caught all of them and its now merged to devel. It is working on QA Staging if you want to give it a try.

Fixing Launchpad Bugs

At UDS, I met the Launchpad folks, who encouraged contributions to Launchpad itself in a couple of sessions. I’ve tried twice before and always get stuck with the getting a virtual machine set up stage. This time, I decided that I’m going to skip that step and go ahead and install it on my lucid laptop. As soon as I got back, I looked at getting the launchpad source code. rocketfuel-setup is a 400-line shell script that does the heavy lifting of the installation for the user. After having written such a script at work, I have huge respect for the author of this script 🙂

After installing, I looked around for a simple bug to fix and picked [bug1][bug 645825]. The bug appeared easy enough to fix and I had a fix ready in a few minutes. I proposed a merge and was told that it needs work. It needs test cases! Another day I spend with poolie, jml, and gmband a few hours of learning to write test cases for Launchpad. Gmb and I used etherpad to collaboratively write the test and I’ll be honest, that was great fun and very productive. Multiple tries and we finally got it right and he landed it in ec2 for the entire set of tests to run. The tests failed.

I quickly popped by #launchpad-dev and wgrant and mwhudson helped me fix and wgrant landed it into ec2 for me. It passed and I did a qa on qastaging.launchpad.net! I’ll be honest that it was an extremely proud moment. This kind of made me want to fix another bug and I found bug 203478. This was something that did irk me before UDS. This time, [deryck][deryck] helped me with writing the test cases correctly first, watching it fail, fixing the bug, and then watch the test succeed. Did something hugely silly this time. I was running the test in a new branch and writing code in the devel branch, which would lead to test not being found, fix not being effective and a bunch of problems. Lesson learned is to use only my branch never the devel branch.

Overall, I liked fixing LP bugs though I’ve been told that its a brave move. The Launchpad developers have been extremely friendly and welcoming for new community developers. I think I’ll take more time to figure out the more complex bugs, but its fun helping fix the ones I can.

Edit: I missed mentioning – Launchpad can’t take a patch until you’ve signed the contributor agreement.