Showing the number of affected users
Published by Martin Pool December 15, 2009 in Bug Tracking, Coming changes, Cool new stuff
Gavin just landed a very welcome branch to show the number of users affected by a bug on the bug page (bug 494040). You can also sort a list by the number of users affected, and doing this shows that two other popular bugs are related: provide a list of bugs affecting a user (283539) and show the number of affected users in a bug list (271332).
Needless to say, the bugs that affect the most users aren’t always the ones that should be fixed first. But it’s useful data, and more useful now that it’s easily available.
You’ll be able to use this after the release of Launchpad 3.1.12 on Wednesday the 16th December or on Edge right away.
Connecting Ubuntu, Upstreams and Users.
Published by kfogel in General
Since we started focusing on bridging the gap between upstream projects, users, and distribution packagers, we’ve been talking to a lot of people, to help us better understand the size and nature of those gaps.
(Those conversations are continuing, too — if you’d like to be a source, especially if you’re an upstream developer whose software is packaged in Ubuntu or Debian and you’ve seen bug reports, translations, or other data come to your project via Launchpad, then please see Matthew Revell’s invitation.)
Meanwhile, we’ve started to synthesize what we’re hearing so far. Recently I went through the raw data to distill it into key points. I filtered out some stuff that had nothing to do with bridging the gap, or that was only mentioned by one or two people. (Conversely, I kept some stuff that I know we’ve heard mentioned by multiple people, even though I may only be able to offer one or two citations here.)
Filtering notwithstanding, what’s interesting is how consistent a lot of the feedback is. The same points kept showing up over and over:
- Speed: Launchpad needs to be faster.
Cited by:
- Sandy Armstrong
- Jussi Schultink
- Ted Gould
- Marjo Mercado
- Jorge Castro
There is universal agreement on this. We’re working on it everywhere, as there isn’t one magic fix that will solve it for all of Launchpad.
- PPA-of-the-day is highly desirable! The easier it is for users to test, the more testing they will do. Therefore, instant packaging of latest upstream code would be awesomelicious.
Cited by:
- Scott Ritchie
- Sandy Armstrong (more or less)
- Carl Richell
- Ted Gould (see “continuous integration” in his page)
- Jorge Castro
Yup. We’re working on this right now.
- Forward bugs more easily, more quickly, and link upstream back to original reporter. (Bryce Harrington, for example, scripts Launchpad very heavily to get what he wants; he points out that the original reporter of a bug should not have to create an account in the upstream tracker to be contacted by upstream — simply having filed in Launchpad should be enough.)
Cited by:
- Sandy Armstrong (as an upstream, wants timely forwarding)
- Bryce Harrington (as a reporter, wants ease-of-forwarding)
- Jorge Castro
We’re trying to nail bug heat and bug Q&A first, but we’re keen to do this too.
- Branch/patch equivalence: Transform one into the other in one click, and push changes easily to upstream in the form upstream prefers.
Cited by:
- Jorge Castro
- Cody Russell (sort of)
- Sidnei da Silva
This is a high priority; we’re working on it!
- Be able to instantly see attributes of comments or commenters in a bug. E.g., tag the comment as “workaround”, have the commenter be displayed differently because of their role, their credibility, or some other quality. Seeing that kind of information in the UI would save a lot of time.
Cited by:
- Sandy Armstrong (sort of)
- Jussi Schultink
- Ted Gould
This would be great. It’s not on Canonical’s roadmap right now, but we’d certainly be interested in helping any community developer who wanted to have a go at it.
- Get more, better information from users in bug reports (e.g., many don’t say the version number of the software). Jussi Schultink mentioned some kind of LP-integrated screen capture would be great; I’m not sure how that would work, but it’s a neat idea.
Cited by:
- Sandy Armstrong
- Jussi Schultink
- Bryce Harrington
This is more a set of related ideas than a fleshed-out requirement, but bug Q&A is probably a step in the right direction.
- Launchpad’s search is ill-placed in the UI and/or ineffective
Cited by:
- Jussi Schultink
- Ted Gould
- Ryan Paul
Insofar as placement goes, that should be a relatively easy fix. As for functionality, we should identify exactly what is going wrong (the raw data has more details). On a semi-related note: probably a lot of the searching people do in Launchpad is with the expectation of finding a match somewhere in the vast bugs database, in which case the new inline dupe-finding may help improve that experience, or at least reduce the necessity of having it.
- Make it easier to find patches that distro should integrate. This could be a tool that would help everyone: not just Ubuntu, but other distros and upstreams too. Part of the trick is to look at other distros’ trackers for patches, not just at upstream.
Cited by:
- Jorge Castro
- (Others say this too, just happens not to be in the notes I trawled this time… but I know it’s out there.)
This is ultimately the “patch report” functionality that was discussed at UDS. While the full story is quite extensive and probably will not be in Launchpad 4.0, some of the sub-stories will be, in particular the parts that make it much easier to quickly see patches attached to Launchpad bugs, and to generate reports about patches.
- Better bug dup searching, better UI for handling bug dup scenarios
Cited by:
- Ted Gould
- Marjo Mercado (esp bugs in other trackers)
- Access to older PPAs would be great. (Then users could figure out when a bug was introduced, for example.)
Cited by:
- Scott Ritchie
- Ted Gould
- Cross-distro bug forwarding. E.g., LP copies a bug from Fedora’s tracker and then forwards it to the proper upstream.
Cited by:
- Sandy Armstrong
- Jorge Castro (in private conversation)
- More ways to view bugs. E.g., omit “fix committed” bugs from list.
Cited by:
- Sandy Armstrong
- Jorge Castro (IIRC, not sure it’s actually in his page)
Interesting that three of those last five related to searching & reporting.
I know much of the above just confirms the direction we’re already going, but I wanted to share it anyway. The emphasis on speed over features was a bit of a surprise to me; good to know.
If you’re really feeling squirrelly, go look over the raw data itself. I left a lot. out above; users have lots of ideas about how to improve Launchpad (as well as much praise for it), and it’s kind of fascinating reading: https://dev.launchpad.net/Strategy/RawData.
The interviewees were:
| Bryce Harrington | Canonical – X.org stack |
| Carl Richell | System 76. Linux computers, yay! |
| Cody Russell | Canonical – Desktop Experience |
| Jorge Castro | Canonical – Ubuntu Community |
| Jussi Schultink | IRC Council, Kubuntu / Ubuntu Studio |
| Marjo Mercado | Canonical – Ubuntu QA |
| Ryan Paul | Gwibber upstream |
| Sandy Armstrong | Tomboy upstream |
| Scott Ritchie | Packager, mostly for universe, esp WINE |
| Sidnei da Silva | Canonical – Landscape |
| Ted Gould | Canonical – indicators / sys status |
The sources include a fair number of Canonical employees. That’s just because we had easy access to them right away, while we were still tracking down upstream developers to interview. We will continue to talk to both, but our emphasis is now on upstream developers and on the people who bridge the gap between upstreams and distribution.
Read-only 22.00-23.00 UTC 16th December 2009
Published by Matthew Revell December 10, 2009 in Notifications
Launchpad’s web interface will be read-only from 22.00 UTC on Wednesday the 16th December 2009 for the release of Launchpad 3.1.12. During that time, other services including PPAs, code hosting and the email interface, will be offline.
Starts: 22.00 UTC 16th December
Expected back: 23.00 UTC 16th December
This is the final Launchpad code release of 2009! We’ll post the 2010 release calendar here in the next few days.
Follow Launchpad’s official status feed for full status information.
Inline dupe-finding: an exercise in pain reduction
Published by Graham Binns in Bug Tracking, Cool new stuff
For the last million years1 or so I’ve been working on a cool new feature for Launchpad Bugs: an inline, AJAXified, asynchronous dupe finder.
For quite some time now people have encountered timeouts or long response times when trying to file bugs, particularly when they enter a long bug summary or the project that they’re filing the bugs on has a lot of bugs through which Launchpad has to search in order to be able to find possible duplicates. The upshot was that whenever a timeout occurred people were unable to file a bug and would have to back up and start again. Needless to say, this was frustrating for all involved.
The new inline dupefinder, which you’ll now find on the “Report a bug” page of any project in Launchpad (when viewed on edge.launchpad.net) is designed to stop this from being a problem, or at least to reduce the problem to a more manageable level and stop it from getting in peoples’ way. It does this in two ways:
- The inline list of duplicates is much quicker to render than a full Launchpad page.
- If the search for duplicates times out for some reason you’ll still be able to file a bug.
Here’s the catch: we need your help. Launchpad’s development cycle this month is very short due to the approaching year-end holiday period, so we need to get as much testing done on this as possible. Check out the dupe finder, see if it works for you and, most importantly, report a bug if it doesn’t.
One last thing: at the time of writing, the inline dupe finder only works for projects (like Launchpad Bugs), not for packages or project groups. We’ll hopefully be enabling it for project groups today and with a bit of luck for packages, too. We started off with projects only because it’s the simplest implementation of the concept and it gives us a good base to test from.
Thanks in advance for your help. Let’s make Launchpad awesome together!
1 This might be an exaggeration.
Phone interviews about your Launchpad usage
Published by Matthew Revell December 8, 2009 in General
In the Canonical Launchpad team, we all use Launchpad every day. As you’d expect, we also have a lot of contact with people who use Launchpad, both for Ubuntu and other projects.
While personal experience of Launchpad and informal contact give us an insight into how some people use Launchpad and what developments we can introduce to help people do more, we want to cast the net wider.
That’s why, at last month’s Ubuntu Developer Summit in Dallas, I kicked off a new series of Launchpad user interviews.
The next set of interviews will be by phone, later this month, and I’d like to invite you to take part. It’ll take between 30 minutes and one hour and I’ll pay for the call 🙂 During the conversation, I’ll ask you some straightforward questions about how you use Launchpad.
Right now, I’m mostly looking for people who act as a bridge between Ubuntu and an upstream project. For example, you may work on an upstream project (whether or not it uses Launchpad isn’t important) and you occasionally check Launchpad to see what bugs Ubuntu users have filed against that project as it is packaged in Ubuntu. Or maybe you translate both for an upstream project and you work on translations for the project’s Ubuntu package.
That’s not a strict requirement, though: I’m interested in hearing from everyone who wants to talk about their Launchpad usage.
If you’re interested, send me an email (my first name dot my last name at canonical dot com) with a brief description of what you use Launchpad for and I’ll choose ten people for this initial set of phone interviews. Also, let me know your availability for a phone call.
Read-only 22.00-23.30 UTC December 3rd
Published by Matthew Revell December 3, 2009 in Notifications
Launchpad’s web interface will be read-only for 90 minutes from 22.00 UTC December 3rd. At that time, all other Launchpad services — including PPAs, bug mail and code hosting — will be unavailable.
Starts: 22.00 UTC 3rd December
Expected back: 23.30 UTC 3rd December
I’m sorry that we’ve had to disrupt your service twice in two days and for the short notice of this coming interruption. During our December 2nd code release we encountered some problems and decided to delay the roll-out in order to resolve them.
You can stay up to date with Launchpad system status by following our identica account.
Getting the most from bug mail
Published by Matthew Revell December 2, 2009 in Bug Tracking
If you’ve reported, commented on or subscribed to a bug in Launchpad, you’ll have seen Launchpad’s bug mail. It’s probably the easiest way to stay up to date with the bugs that interest you and there are a few things you can do to get the most out of it.
If you don’t read anything else…
Probably the best thing you can do to make bug mail useful is to ensure you only get the bug mail that interests you.
Launchpad makes the reasonable assumption that, if you report, comment on or subscribe to a bug, you’re interested in that bug. So, it’ll send you email updates when:
* someone changes the status, importance or targeting of the bug
* someone makes a comment on the bug.
If you find you’re no longer interested in a particular bug, check for an unsubscribe link in the footer of the bug mail. You can also visit your own bug page to check which individual bugs you’re subscribed to.
If you don’t see an unsubscribe link, it means that you’re not subscribed directly. Instead, you’re receiving the bug mail because either:
- you’re a member of a team that’s subscribed to the bug
- you’ve previously subscribed to receive all bug mail associated with a particular distro, project or part thereof.
So, what do you do?
You’re subscribed to all bugs associated with a distro or project
At the bottom of the bug mail is a link to the bug’s page in Launchpad, along with a short explanation as to why you’re receiving the bug mail. If you’re subscribed to all the bugs associated with Launchpad, for example, it might say:
You received this bug notification because you are subscribed to Launchpad itself
These bulk subscriptions do not show up on your bug page. Instead, you need to visit the distro, project or series’ bug page and follow the Subscribe to bug mail link, where you’ll be able to unsubscribe.
A team you’re in is subscribed to the bug
Similarly, if you’re subscribed to a bug indirectly through your membership of a team, the bug mail footer message will tell you which team. You now have two options to stop receiving the bug mail:
- leave the team
- if you’re absolutely certain your team-mates will be happy, unsubscribe the team from that bug, by following the link to the bug’s Launchpad page.
Of course, there is another way that isn’t as drastic as either of those two options: instead of unsubscribing, filter the bug mail to a dedicated folder.
Filtering bug mail
Most mail clients can filter your incoming mail based on certain elements, such as text in the subject line, certain mail headers and so on. Launchpad makes it easy to filter bug mail.
The most obvious thing you can use to filter your bug mail is the subject line: Launchpad adds the bug number to the start of each bug mails subject, such as:
[Bug 123456] Add some whatsits to the doodah
The footer, which explains the reason for your receiving the bug mail, can also be handy. Similarly, Launchpad adds an X-Launchpad-Message-Rationale: header to each bug mail, which you can use to filter the bug mail.
Matt Nuzum wrote an excellent guide to filtering Launchpad bug mail. It’s aimed at Gmail users but you can tailor it to your own mail client.
Duplicate bugs
If you’re subscribed to bug A and someone marks bug A as a duplicate of bug B, Launchpad automatically subscribes you to bug B. You can always follow the unsubscribe link in the mail footer.
Two-way bug communication
Before I go, I should mention that bug mail is not just a one-way conversation. You can report, comment on and alter bugs entirely by email. It’s quick and really easy. Take a look at our guide.
Don’t forget that if you reply to bug mail, your entire email will be published as a public bug comment on Launchpad. So, remove those phone numbers from your email signature if you don’t want them to be public!
Launchpad read-only 22.00 UTC 2nd December 2009
Published by Matthew Revell November 30, 2009 in Notifications
Launchpad’s web interface will be read-only for roughly 90 minutes from 22.00 UTC on Wednesday the 2nd of December 2009. Other aspects of Launchpad — including code hosting, PPAs, the API and email interface — will be unavailable during that time.
Starts: 22.00 UTC 2nd December 2009
Expected back: 23.30 UTC 2nd December 2009
During this time, we’ll be releasing the code for Launchpad 3.1.11.
The next planned down-time for Launchpad will be for our 3.1.12 release on the 16th December. We’ll publish the exact time, nearer to the release date, on our status page.
You can also see the Launchpad release calendar to check for future release down-time. We’ll be publishing the 2010 calendar soon.
Code hosting and browsing offline 13.00-17.00 UTC 19th November
Published by Matthew Revell November 17, 2009 in Notifications
We’re upgrading the disk space available for Launchpad’s code hosting! During the upgrade, we’ll have to take code hosting and browsing offline.
Going offline: 08.00 UTC Thursday 19th November
Expected back: 12.00 UTC Thursday 19th November
We’re sorry that you’ll be unable to browse, push to or pull from code hosted by Launchpad during this time.
You can stay up to date using Launchpad’s official system status feed (Twitter version).
UPDATE: We’ve updated the time of the down-time. It is now 08.00-12.00 UTC.
November Lazr-js Sprint Report
Published by Paul Hummer in General
Last week, members of the Launchpad team got together with members of other teams across Canonical to sprint on lazr-js. lazr-js is the library the Launchpad team created on top of the Yahoo User Interface 3.0 javascript library to provide a richer user experience. For instance, the “widgets” in lazr-js are used in bug pages to help users change bug status and importance without leaving the bug page, and allowing users to subscribe to a branch without leaving the branch page.
One of the big things we focused on with lazr-js last week was integration into apps other than Launchpad. We worked with members of the internal Canonical webapp teams, the Ubuntu One team, and the Landscape team to get lazr-js integrated into those apps, and find the issues that anyone would have while trying to integrate lazr-js into their own app.
As we focused on integration, we were able to see where we could make lazr-js more generic and easier to use. We were able to find ways to automate the tests we have written for the code in lazr-js. We also focused on fixing the bugs in lazr-js that would prevent Internet Explorer users from benefiting from lazr-js enhancements to an application, but we still have much to do in the way of cross-browser compatibility. We’ll be working towards browser compatibility in the next few months, and welcome any contributions from the community.
The sprint was a huge success. At the beginning of the week, lazr-js was a Launchpad library, and at the end, it became a library that can be used by anyone that wants to have a rich browser experience for their webapp.
