launchpadblog

As we foreshadowed last October, bug expiry is now active again.

Bugs that are marked Incomplete and that haven’t been touched for 60 days will now start moving to the Expired state. If it turns out the bug’s still useful or valid, anyone can move it back.

We recommend people use the Incomplete state to mean: if this bug report doesn’t get more information, there’s nothing we can do with it.

This only affects projects expire incomplete bug reports setting turned on in the Configure bug tracker page.

Polls were introduced to Launchpad as a way for teams to conduct internal surveys.  Unfortunately the user interface and feature set were always problematic.  The feature never really caught on and wasn’t used much (a little over 500 polls since 2006).

A discussion[1] on the Launchpad Users mailing list saw a consensus agree that polls in their current state were not a viable feature and they should be removed rather than being fixed.  As part of the December Launchpad Bug Jam I’ve taken on the task of removing them from the site.

Currently there are only four polls that are underway and the owners of the teams responsible for those polls will be notified that the feature is being removed.  The data from all existing polls will be saved and made available to the teams at PollFeatureRemoved.

[1] https://lists.launchpad.net/launchpad-users/msg06098.html

Via Planet Launchpad: Launchpad’s Strategist, Jonathan Lange, writes on his blog:

We’re starting to get a picture of what we want to do in the second half of 2010. In particular, lots of people within the team and within Canonical are starting to get fed up with our privacy and permissions model, which is quite patchy. It’s currently tangled up with the way we send emails to people, and we’d love to untangle them.

The Foundations team are already at work making Launchpad faster, and that’s something we want work on even more in the coming months. Derivative distributions – that is, a Linux distribution that extends or customizes another one, generally Ubuntu – have always been a key part of the vision for Launchpad, and they are finally going to get the effort they deserve.

Finally, we want to do whatever we can to make the Ubuntu Software Center rock harder than it does already. Launchpad occupies a special place in the Software Center world, since it can help make it easier to get applications for your desktop and make it easier to develop those applications.

If you’re keen to know what we have planned for Launchpad, you can subscribe to the roadmap page on our dev wiki.

It’s my pleasure to introduce to you the single greatest Launchpad planning achievement for 2010: the roadmap.

For the last few months we’ve been working on bridging the gap between the Ubuntu distribution and the upstreams that it’s made from: making it easier for patches, translations, and bug reports to flow between Ubuntu users, Ubuntu developers, and upstream developers.

We’ve been asking users what they want and trying really hard to listen to them. And, of course, since we’re Free Software now, all of our discussion, development and planning is out in the open.

Still, there are a lot of people who care a lot about Launchpad but don’t have time to follow our mailing list or dev wiki. In particular, Ubuntu contributors are generally way too busy making Ubuntu better to keep up with every thread there. If people who care about Launchpad can’t keep track of what we are doing, they can’t tell us how we can do it better, and they can’t cheer us on when we’re doing it right.

We needed something to keep everyone in the loop. But it needed to be something simple, since we don’t want to spend all of our time telling people what we are going to do instead of actually doing it.

At Kiko’s urgings (perhaps inspired by Jono Bacon’s roadmaps), we’ve prepared a roadmap for the next few months of Launchpad development, in which the highlights are:

• Guiding developers to the most important (hottest) bugs
• Getting patches attached to bugs into the code review system
• Automatic imports into bzr from hg (we already do git)
• Ubuntu packages built fresh each day from the latest code

And of course, there’s more on the roadmap.

We intend to keep the page up-to-date and to keep the URL constant. This means that any time you want to know what we’re planning, you can look at that page and know for sure.

Remember, it’s an expression of intent, and not an actual commitment. If we can figure out a way to better connect the world of open source software, we’ll change the roadmap in a heartbeat.

For those who aren’t content with a high-level overview, you can also look at the 10.5 series on Bugs, Soyuz, Code and so forth. See the page for our current development cycle for a full listing. And, of course, you can keep following this blog for major announcements and items of interest.

I hope you enjoy the Launchpad roadmap, and I can’t wait to hear back from you. Have a great 2010.

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.

Yesterday, our new design has started to roll out on the edge servers. This will be an incremental and iterative process, as all the pieces come together, where our best ideas and speculations meet production data.
One of the conversations we had when re-designing the Launchpad UI, was that projects should be more on the foreground. They are what make Launchpad great, and the more projects that use it, the more powerful the tool gets. While breadcrumbs are still being worked on (they will look more like breadcrumbs and be more detailed), project pages now highlights the project’s logo and name:

New changes being rolled out on a daily basis. Exciting times!

Now that we’ve released Launchpad’s source code, our next couple of months of work are going to be mostly focused on our page layouts.
Launchpad has been around for quite a few years now, and tight release schedules packed with ever-changing features have had the side effect of us ending up with a lot of pages with different layouts.
In the next 2 months, we plan to fix that, and make sure every single page in Launchpad (452 templates!) has our new “3.0 look n’ feel”.
What does that look like, you may ask yourself?

Well, we’re still working on it, as we’re going to change the UI for the navigation (as well as tweak it’s functionality a bit, more on navigation in a future post). We do have rough draft which we’re starting to work towards, figure out what works and what doesn’t with real data, things we didn’t think about, etc.

The first major page we’re converting is the project overview page, currently being worked on by the world famous Curtis Hovey, and the initial draft should look similar to this:

It’s important to note we’re still working on the UI, so the image above is our starting point rather than the end product.

Since it will take some time to make all the changes, we’re most likely not going to make a Launchpad release in August, and jump straight to September. Roll-outs to our edge server will continue to happen daily, and we’ll need your feedback on the changes more than ever. If you’re interested in helping us, just join the beta testers team.

Exciting times!  🙂

After many months on working on the necessary infrastructure to deploy complex AJAX widgets in Launchpad, more user interface reviews than any developer would like to go through in a life time, and a lot of cursing, the tip of the iceberg is finally showing.

Mark announced months ago the level of complexity we where aiming at achieving, and this last roll out of Launchpad actually places us very close to that.

Micheal Nelson did some amazing work, and landed the first of many pop-up widgets, allowing you to mark a bug as a duplicate without needing to refresh the page:

You will start to see that some links in Launchpad are green, those will mean that you will get an AJAX experience instead of going to another page. Check it out in bugs:

Tom Berger and Abel Adeuring also switched to javascript ninja-mode, and cooked up a slick UI for managing official bug tags:

In our 2.2.3 release of Launchpad — due 1st of April — we’re strengthening the relationship between milestones and releases.

Project releases will be explicitly linked to a milestone, meaning the release inherits the milestone’s series and identity information.

You’ll be able to create a new release from a milestone page or, if you don’t yet have a milestone, there’ll be an option to create a release and its parent milestone simultaneously. You can still have milestones that do not correspond to releases.

Just as now, the release will hold the release notes, changelog, date released, and any downloadable files.

What are Releases, Milestones, and Series?

Launchpad hosted projects can arrange their development into Series, which contain Milestones to which bugs can be targeted, and Releases which hold download tarballs and have release notes. Although Milestones and Releases go together, they were previously managed separately in Launchpad. Now they’re more unified.

Why are we doing this?

Many people already use releases and milestones in this way. Milestones aid release planning, and help people understand a project’s goals. Creating a release directly from a milestone implies that the milestone was reached.

Linking milestones to releases improves the data consistency between projects. With good milestone and release information, Launchpad can improve the presentation of series to explain what has happened, and what will happen. We hope that this will make it easier for people to know where and when to make contributions to your project.

This change also allows us to redesign the series, milestone, and release pages. Our goal is to better present the history and future of a project, as well as to improve the workflow for planners.

What you can do

You do not need to take any action regarding releases. We’re migrating existing releases by linking them to a milestone, or if there isn’t an appropriate milestone, creating a new one.

You can use Launchpad’s staging environment — https://staging.launchpad.net/ — right now to check what your releases
and milestones will look like under the new system.

We’d value your feedback so we can improve the data migration script. If you come across a problem, please report a bug here:

https://bugs.launchpad.net/launchpad

For other comments, send us an email to feedback@launchpad.net

How we’re making the migration

The release’s project, project series, version, code name, and summary come from the milestone it’s linked to. The release’s version will come from the milestone’s name.

When a release and a milestone share the same series and version/name, they are linked. The release’s summary will be appended to the milestone’s summary. You should review your project’s milestones. You can make changes to your project’s milestones and releases on launchpad.net to ensure they are merged correctly on staging.launchpad.net before the final migration.

When no milestone can be matched to a release, a new milestones is created from the release’s information. The milestone is not active, they will only appear on the project’s milestone page. There are a few instances where two series have a release of the same name. Milestone names are unique across a project. So the milestone’s name will contain the release’s version and series name (0.9-series-trunk). You can prevent this from happening by renaming some of your project’s releases on launchpad.net now — in most cases, the duplicate release name is on an obsolete series, or trunk. You can view all your projects series at:

https://launchpad.net/<your-project>/+series

We’re also taking the opportunity to rename a couple of things: description” becomes “summary” and the milestone’s visibility flag (in the REST API) is renamed to “active”.

We believe this change will make releases and milestones much more useful. Please do report bugs or email us if you have any comments.

A few days ago a fix for bug #286359 landed: provide translation import notifications to Ubuntu packagers. This means that all packagers will start getting emails about translation files (basically, *.pot and *.po files) from their packages as soon as they are imported (or the import fails).

This should help packagers detect and fix l10n-related problems more easily, since they’ll have most of the debugging information they need right inside their inboxes. If you want to filter these emails, look for a sender of rosetta@launchpad.net.

The grey area of where to send notifications for automatically synced package uploads from Debian remains. I am planning on solving that with a public mailing list where anyone interested can go in and check for problems, and also fix them if they want to. Alternative is to rely on the recent improvement by Jeroen which keeps any failure messages inside the import queue itself, and simply drop all of these messages altogether.