launchpadblog

From today, all Launchpad bugs, code, questions and blueprints are tracked under the one launchpad project.

We’ve already moved everything from the individual projects over to the parent launchpad project. All you need do differently is search/file bugs, questions and blueprints under that parent Launchpad project, rather than Rosetta, for example.

Don’t worry, though, there are redirects in place so that old links will still work.

There are also a couple of one-time steps you may need to take:

• Update your bug subscriptions: if you’re subscribed to individual bugs, you need do nothing. If you’re subscribed to all bugs for a particular project, Malone for example, you’ll now need to subscribe to all Launchpad bugs.
• Check your answer contact status: if you’re an answer contact for one particular application in Launchpad, and want to continue as such, you’ll need to become an answer contact for all of Launchpad.

To start with, bugs that we’ve merged in from one of the old sub-projects will have a tag that shows which project it came from. However, we’re planning to drop those tags once everyone’s settled into using just the one project.

Our code hosting won’t change at all as we’ve always hosted code under the parent Launchpad project.

This new approach will better reflect that Launchpad is one codebase but will also have a big practical benefit: it’ll be easier to find bugs and dupes because everything will be under the same project.

Why we’re doing this

For almost four years now, Canonical’s Launchpad team has been divided along application lines: i.e. we have sub-teams who each look after a particular part of Launchpad. So, Deryck, Abel, Gavin and Graham are currently the Launchpad Bugs team and work on nothing other than Launchpad’s bug tracker.

Reflecting this team structure in our Launchpad projects has made it easier for those sub-teams to plan their work.

It has worked pretty well but we’re about to change the structure of Canonical’s Launchpad team for a couple of reasons:

• we want to focus on releasing features, and fixing problems, wherever they are
• we want all Canonical Launchpad developers to be familiar with the full Launchpad codebase, rather than focusing only on one part.

So, as of February 17th the Canonical Launchpad team will have five squads. At any one time, three of those squads will each be working on a particular feature and the other two will be working on maintenance. Once a feature squad finishes its feature, it’ll switch places with one of the maintenance squads.

This will mean that there’ll always be ten Canonical Launchpad developers dedicated to fixing bugs, dealing with critical issues and generally making sure that Launchpad is serving you well. And of course there’ll be fifteen developers working on new features.

Rather than make this post even longer, I’ll write more soon and in the meantime point you to Rob Collins’ rousing launchpad-developers post in favour of the new structure.

As ever, if you have questions then please join us on the launchpad-developers mailing list or feel free to contact me directly.

Tags: front-page

This entry was posted by Francis J. Lacoste on Wednesday, December 15th, 2010 at 10:23 pm and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.