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:
- 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:
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.
