0

Showing the right bug comments

Published by Matthew Revell August 13, 2010 in Bug Tracking, Cool new stuff

Some bugs attract many, many comments.

For a while now, Launchpad has displayed only the first 80 comments on any bug report, with the option of viewing the full comment history. That’s been good for speeding up page loads but not so great at offering an accurate view of the current state of discussion about the bug.

Bryce has fixed that. Now, a bug report page still shows only 80 comments, by default. However, to give a better overview of the state of discussion, it now shows the first 40 and the last 40 comments.

So, half way down the comments you’d see something like:

Then, at the bottom of the summarised comment history there’s this:

With any luck, this should result in new bug comments that take into account the most recent discussion.

---

1

Better dupe finding

Published by Matthew Revell in Cool new stuff

One of my favourite things about Launchpad’s bug tracker is the dupe finder: when you report a new bug, it’ll search to see if there’s already a similar bug report. It’s the same for questions in Launchpad Answers, too.

Getting to see possible dupes before you file a bug or question is a great time saver for you and the people on the other end. However, the dupe finder has been timing out a lot lately.

Rob Collins, Launchpad’s new Technical Architect, has introduced some changes that should make the dupe finder more reliable.

Other than fewer timeouts, here’s what you might notice:

• the dupe finder now returns fewer matches — three or four rather than ten or more
• the results should be more relevant.

We want to know how this works in practice. Let us know how you get on with the new dupe finder. Either leave a comment here, mail feedback@launchpad.net or join us on the launchpad-users mailing list.

How Rob did it

The previous dupe finder had a number of problems, not least that the search engine it’s built on is less efficient than we need. We’re planning to replace the search engine but not straight away, so Rob looked for a temporary solution that would work for the next five or six months.

I’ll hand over to Rob to explain what he actually did:

The old search did a pre-pass over every possible hit, which is 400,000 items for Ubuntu bugs and very slow to do. It then did a search matching any document that had a rare search term in it.

So, by rare we mean that the term showed up in less than half of the possible hits.

For example, if you searched for “firefox crashes on <website> in flash” on /ubuntu/+filebug it would search for any bug with any of “firefox” (< 50% of bugs are on firefox), "crash" (<50% of bugs say "crash"), "<can switch this off easily if we have to, so we do want feedback about how people find this.

---

0

Launchpad read-only 08.00-09.30 UTC 12th August

Published by Matthew Revell August 3, 2010 in Notifications

Launchpad’s web interface will be read-only (most other aspects will be offline) for 90 minutes on August 12th while we roll-out the latest code.

Going offline: 08.00 UTC 12th August 2010
Expected back: 09.30 UTC 12th August 2010

For up to the minute Launchpad status information, visit our status feed.

---

4

Launchpad’s Build Farm Improvements

Published by Julian Edwards August 2, 2010 in Cool new stuff

Improvements, you say?

Very recently we saw the beta release of a new feature on Launchpad: building packages from recipes. Recipes bring Bazaar branches for the upstream source code and a packaging branch together to generate a Debian source package. We informally referred to this internally as “the Wellington project” because we first embarked on this long road of development back in November 2009 with a coding sprint in Wellington, New Zealand.

So, why do we need to use the build farm for this?

Very early on we realised that this would be a challenging project because packaging recipes allow untrusted arbitrary code to run as part of building the package, so we decided that the only place we could do this operation was in the same place that we do one of the other untrusted operations – the PPA build machines.

The PPA build machines work for untrusted code because they run as a virtual machine. After the build job has finished, the machine is simply ripped out and restarted so if any code did something nasty, we throw all the nastiness away!

Why can’t the build farm do this already?

The Launchpad build farm has been around for a while now, but it’s of course only used for building source packages into binary debs. We realised that we’d need a whole new data model on the Launchpad side, changes to the master/slave protocol and changes in the slave code to make it actually run this new job type – a lot of work! It was also about this time I became aware of a further untrusted job type, generation of translation templates for Launchpad Translations, so we began work on making the build farm able to process any kind of job.

What had to change?

By far the biggest change for this was to fix how we store the build/job information in the database. The canonical way to refer to a “job” on the build farm was via “build” record, and this is what all of the history pages in the UI were using. We’ve now re-architected this to use a generic “build farm job” and a bunch of new database tables that re-factor all the information needed for various jobs on the build farm, in fact we found out that the recipe build jobs and the source package build jobs had quite a lot in common which resulted in some merciless code re-factoring indeed.

The other major change was the slave builder code itself. This runs as a Twisted executive that we talk to using XMLRPC from the build manager, which kicks off external processes to run the job and monitors them. The only job it knew about was to run sbuild to build source packages. We’ve changed this to also run bzr builder and a custom script to generate the translations templates.

So, will I see anything different?

You won’t see much visually that’s changed in the Build Farm. If you’re observant, you’ll see the occasional job appear in the list that announces it’s a recipe build, but they’re generally pretty quick to complete!

We’ll post a more detailed explanation of how to use recipe builds in the future, but for now it’s remaining in beta until all the problems are ironed out. If you have any feedback, please file a bug or send us an email.

---

0

Assigning bugs to someone else, or not

Published by Deryck Hodge July 29, 2010 in Bug Tracking, General

Recently, we changed the way assigning bugs works on Launchpad. It used to be that anyone could assign anyone else to a bug. This was open to abuse as you can imagine. Bug 511269 was filed about the potential problems with this, and we recently changed Launchpad so that only bug supervisors can assign a bug to someone else.

You can still assign a bug to yourself, but this does keep you from assigning someone to a bug to draw their attention to said bug. In the end, this is a good thing, though, as people should only be assigned bugs who are going to be responsible for working on them.

Now there is one issue with this change. Projects that had not established a bug supervisor for the project will find their developers can no longer assign bugs to each other. The easy fix for this is to create a bug supervisor team for your project and have the people working on your bugs assigned to this team. We do realize this might be a bit heavy weight for some projects, so we’ve opened bug 603281 about this issue.  A fix for this — only requiring bug supervisor permissions if bug supervisor is defined — should be appearing on Launchpad soon.

---

1

Meet Benji York

Published by Matthew Revell in Meet the devs

Recently, Benji York joined Canonical’s Launchpad team. I asked him a little about himself and his work.

Matthew: What do you do on the Launchpad team?

Benji: I work on the Foundations team. Right now I’m concentrating on the web service APIs and improving the OpenID integration.

Matthew: Can we see something that you’ve worked on?

Benji: There’s not much to see yet. Most of my changes thus far have been bug fixes or purely internal.

Matthew: Where do you work?

Benji: I work from my home in Virginia, USA.

Matthew: What can you see from your office window?

Benji: Just the shrubs that border my lawn. Once the weather cools off a bit I want to try working from the wifi-covered park/beach near my house.

Matthew: What did you do before working at Canonical?

Benji: I worked at Zope Corporation for about 6 years, most of that time as the team lead for their main product. Before that I worked in the automotive industry, mostly writing supply chain and manufacturing software.

Matthew: How did you get into free software?

Benji: I think the first piece of open source software I used to any degree was Python 1.5. Since then open source software has slowly taken over almost every niche of my computing world.

Matthew: What’s more important? Principle or pragmatism?

Benji: Pragmatism. If a thing doesn’t do what it needs to do, it’s not worth much.

However, I believe that principles are there to help us be pragmatic in a scope larger than the immediate moment. It’s not pragmatic in the long term to skimp on good design or testing just to get something out the door. Any good principal is grounded in pragmatism.

Matthew: Do you/have you contribute(d) to any free software projects?

Benji: When I was in college the console (NES, SNES, Genesis, etc.) emulation scene exploded and I had a side project that let people connect console controllers to their PC. I was approached by one of the Linux input device guys about contributing some of that code. That was my first open source contribution.

Since then I’ve made large and small contributions to dozens of open source projects. Most of those have been in the Zope ecosystem.

Lately I’ve put most of my open source hacking time into Manuel, a system for writing better tested documentation and better documented tests — it’s sort of a spiritual successor to Python’s doctest.

Matthew: Tell us something really cool about Launchpad that not enough people know about.

Benji: I’m sure most readers of this blog will know, but I didn’t know that the Launchpad and Bazaar integration is as nice as it is. Being able to branch from LP, make changes, mark the branch as fixing a particular bug, push the branch to LP, view the diffs online and then generate a merge proposal that will be automatically emailed to reviewers is very convenient.

Matthew: Is there anything in particular that you want to change in Launchpad?

Benji: I’m not familiar enough with LP yet to have strong feelings about changing it. Give it a few months and I’ll be plenty opinionated.

---

1

Testing new designs on Launchpad users

Published by Matthew Revell July 21, 2010 in General

Recently, I’ve been working with Charline, from Canonical’s design team, to talk to Launchpad’s users about how Launchpad fits into their work and what they think of new features we’re planning.

You may have seen my requests for participants on identi.ca and Twitter 🙂

In the past, someone working on a new, or improved, feature would mock-up some ideas and post them to our development mailing list. A good discussion would result but often, not always, people who use Launchpad, rather than develop it, wouldn’t see the implementation until it was available in their browsers.

Sometimes, this meant that minor, avoidable, mistakes were made. Other times it meant that somewhat eccentric workflows made it into production and dampened the impact of what was, otherwise, a cool new feature.

Improving bug subscriptions

Graham Binns has been working on some designs for an improved way to subscribe to bug reports in Launchpad. This is something we hear about a lot and also complain about ourselves: currently, Launchpad offers too little control over how much email the bug tracker sends.

We want to get this right and so we decided that this would be one of the first feature improvements that we’d put through our new mock-up testing process.

Here’s how it worked: Graham sent me his mock-ups and I invited six Launchpad Bugs users to come and tell me what they thought. Each person had an hour, during which I asked them to imagine they were using the mocked-up pages to complete certain tasks. I recorded what they said, while Graham made notes.

This worked better than we could have hoped. Not only did we get to see what worked, what was confusing and what was just plain stupid, we got to hear about how this feature would fit into other people’s lives, giving us an even better idea of how the feature should work.

Based on what the participants said, I wrote a list of recommendations, which Graham used to refine the mock-ups.

The following week, another set of people came along for round two, in which pretty much the same thing happened except we were using Graham’s new mock-ups.

The interesting thing was that, by and large, these sessions were over much quicker than those of the first round. The points of confusion from the first round had been, mostly, ironed out. We had confirmation that the first round worked and the new designs were much easier to work with.

Of course, the new design is almost certainly not perfect but it’s an awful lot better than it would have been were it not for the simple process of sitting down and asking people what they thought.

You can read the full report of both rounds on the Launchpad dev wiki.

Future testing

This is something we’ll be doing a great deal more of. Right now, I’m looking at ways that we can involve a wider range of Launchpad users (i.e. not just people who happen to be able to make it to Canonical’s London offices during work hours). That could mean working remotely, doing more of this at UDS and other events, or even visiting different places specifically to test a feature or two.

If you’re interested in participating, let me know. If you want to follow the progress of this testing, join our launchpad-dev mailing list.

---

2

Launchpad EPIC 2010 photo

Published by Matthew Revell July 16, 2010 in General

The Launchpad and Bazaar teams have been in Prague this week. More on what we got done in later posts. For now, here’s a photo!

---

7

Three tips for faster launchpadlib api clients

Published by Martin Pool July 14, 2010 in API

Three tips from Leonard’s lightning talk in Prague about writing faster Launchpadlib API clients:

1. Use the latest launchpadlib. It gets faster from one release to the next. (The versions in the current Ubuntu release should be fine; otherwise run from the branch or the latest tarball.)

2. Profile:

    import httplib2
    httplib2.debuglevel = 1

will show each http request and response, so that you can see what’s taking time.

3. Fetch objects only once:

Don’t do this:

    if bug.person is not None:
        print bug.person.name

instead

    p = bug.person
    if p is not None:
        print p.name

In the first case, the client may fetch the Person object twice. (We may fix this in future.)

---

12

New Launchpad Bugs Status: Opinion

Published by Deryck Hodge July 7, 2010 in Bug Tracking

Many different types of information are stored in bug reports in Launchpad.

Some are actual defects, some are feature requests, some are general issues, and so on.  It is not uncommon on Launchpad to have a bug that deals with an issue that a developer cannot resolve.  In Launchpad, we offer a couple of bug statuses that allow a developer to close a bug report without actually doing what is requested in the report: these are Won’t Fix and Invalid.

Often, though, there may still be a discussion. Won’t Fix and Invalid are useful for the developer, and the project, to know that they don’t need to schedule time for a fix. However, they can sometimes — rightly or wrongly — be seen as an attempt to close down to discussion.

We’ve just added a new bug status to Launchpad: Opinion. Now, this is a fairly momentous occasion; we hardly ever make changes to bug statuses because they, naturally, have a great impact on how you and others use Launchpad to track bugs. However, we feel it’s important to find a way to balance a project’s need for useful work planning with the need for intelligent and open discussion.

Opinion says: there’s a difference of opinion around this bug and people are free to continue the discussion, but the project or package maintainers need to move to other work and are considering the issue closed.

Like I said, adding a new bug status to Launchpad is a big deal. So, we’re treating Opinion as an experiment. We’ll watch how it is used over the next three months and then we’ll decide if the status is proving useful and effective at closing bugs while leaving the discussion open.

I’d love to hear your views on this new status: leave a comment here, join us on the launchpad-users mailing list or mail me directly.

---

Previous Entries

Next Entries