launchpadblog

We’re coming to the end of the first week of Launchpad’s 2010 Bug Jam. How’s it gone so far?

At the time of writing:

• Jono’s BugJam-o-Meter shows 77 bugs fixed as part of the jam
• most of those 77 have been fixes, with 19 Fix Released and 24 Fix Committed
• just one bug has been marked with the experimental Opinion status during the bug jam
• the hottest bug is 297505: Warn users that mailing list archives are public unless the team is actually private
• the oldest bug tackled is 33203: poll: dates are not properly validated, which was reported on March 1st 2006

Join us in #launchpad-dev on FreeNode or on the launchpad-dev list.

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.

TL;DR

This is a pretty long post. Here’s the important bit, if you don’t want to read the rest.

”’For all Launchpad status updates/notices:”’ use our launchpadstatus identi.ca account (RSS feed, Twitter mirror).

”’For notice of major interruptions only:”’ subscribe to the launchpad-announce mailing list or the Launchpad blog’s notification category.

You can also use the Launchpad release schedule Google calendar (ical).

Improving how we announce service disruption

Over the past few months we in the Launchpad community have been moving toward releasing features with no downtime.

We can already push out new features when they’re ready, rather than as part of a monthly code push. However, we still have some service interruption: what was our monthly code release is now a roll-out of changes to the database’s structure. And, of course, there are times when we need to disrupt to Launchpad’s service in order to maintain hardware and so on.

The way that we announce such planned service interruptions has been a topic of discussion lately in the Launchpad community. I wanted to get a feel for what people beyond the Launchpad development community would prefer and so last week I
posted a survey asking how people would rather we make such announcements.

Before I look at what people said, I’ll note that 126 people completed the survey and that the results are really nothing more than a discussion point; the respondents were self-selecting and there’s no way to know if that 126 people were representative.

What people do now

The people who responded to the survey told us that, right now, they get Launchpad service status information in these ways:

Some of you reading may wonder why email isn’t mentioned. For some time we’ve had a launchpad-announce list specifically for announcing Launchpad service interruptions. However, until now that list hasn’t been well publicised.

What people said they want

In the survey, I asked what method people would prefer to use to get information about Launchpad service interruptions. Rather than limit what people could suggest, I gave an open text box.

The responses divide fairly neatly into six categories.

So, what should we do in light of this?

How we’re going to announce service interruptions in future

We have, broadly, two types of service interruption:

• localised disruptions that most people won’t notice: e.g. code browse offline for less than five minutes
• widespread disruptions that could inconvenience thousands of people: e.g. Launchpad read-only for 90 minutes.

Here’s how we’ll announce them from now on:.

Localised disruptions:

• identi.ca/Twitter notice at least 24 hours in advance
• #launchpad irc topic message at least 24 hours in advance

Widespread disruptions:

• One week before:
  • Email to launchpad-announce
  • Post to the Launchpad blog notifications category
  • Announce on identi.ca/Twitter
  • Ensure the Launchpad release schedule calendar (ical) is correct
• 24 hours before:
  • Reminder post to identi.ca/Twitter
  • Message in #launchpad topic
• Five to ten minutes before:
  • Message at the top of Launchpad pages
  • Reminder post to identi.ca/Twitter

We’ll also look at ways of improving the notification system in Launchpad itself, although any changes are still some way off.

Of course, we’re open to suggestions for how to better announce such disruptions. Please do leave your comments here.

I’m running a short survey — four questions — to find out how people want to get system status updates about Launchpad.

If you’ve got an opinion on how you’d prefer to get info about pending and unplanned Launchpad service interruptions, take the survey 🙂

I previously posted about our continuous deployment efforts in Launchpad. Since then the project has come a long way. We can deploy to nearly all our services without downtime. The remaining services are a bit trickier – but we are working on them.

As part of the project we are consolidating the ‘edge’ domain – https://edge.launchpad.net/, https://bugs.edge.launchpad.net/ and other similar domains – into the main launchpad UI. These domains are now deprecated.

The most important thing this means for you is that for members of our beta test program, we will no longer redirect you to https://edge.launchpad.net/ – instead we are serving our beta UI directly from the main website. The edge site is now running exactly the same code as the main Launchpad cluster and is updated at exactly the same time.

We have done this to deliver new features to our users more efficiently and at the same time simplify our production environment. So far the project has been very successful from our perspective – as I write this we have 5 days of inventory – code we’ve written but not deployed. This is down from an average of 2 weeks prior to this initiative starting, and we often sit lower – 1 to 2 days worth.

In the coming months as we refine this process and project we want to remove the edge cluster. As part of this we will start redirecting browser requests to ‘edge’ domains to the main Launchpad domain.

API clients cannot be redirected in this way, so we also ask that anyone writing or using Launchpad API scripts update them to use the primary cluster. We will slowly decrease the cluster size and disable it completely once we see no traffic on it. The main cluster is currently 3 times the size and should perform better for nearly any API script. To do this, use LPNET_SERVICE_ROOT rather than EDGE_SERVICE_ROOT. To get the LPNET_SERVICE_ROOT symbol, import it from launchpadlib.uris:

from launchpadlib.uris import LPNET_SERVICE_ROOT

If you have any questions about any of this we’d be delighted to hear from you – here, on IRC or the launchpad-user mailing list.

Rob Collins
Technical Architect

A while back I asked for your suggestions for which Launchpad-hosted projects we should feature on the Launchpad front page.

Thanks to everyone who made their suggestions! I’ve now updated the list based on how often each project was recommended and how active they are in Launchpad.

Visit the Launchpad home page to see the new list and, if you have any suggestions for what you’d like to see there, post your comment here.

Between December 13th and 24th we’re holding Launchpad’s first bug jam!

For two weeks, Canonical’s Launchpad team will focus solely on closing bugs and we’d love it if you’d join us.

Right now, there are more than 6,500 open bug reports for the Launchpad project. During the bug jam we want to close as many of these as we possibly can.

Closing a bug doesn’t necessarily mean fixing it: it may be something that can’t be fixed or even that’s already been fixed.

If you want to take part, or track progress, join the launchpad-dev team and mailing list. You should also take a look at the bug jam page of the Launchpad dev wiki.

We are starting to rollout features more rapidly on Launchpad as we move to a continuous deployment model.  There are some fixes being deployed today that I want to give Launchpad users a heads up about.  These are fixes meant to make the life of a bug supervisor easier.

Bug 114766, Only bug supervisor should be able to nominate a bug for release

Nominating to release has in the past been used as a mechanism to request that the bug be fixed, which is not what the feature is for, and we’ve now made it where only the bug supervisor for a project can nominate a bug for a series.

Bug 347218, Allow bug supervisors to make tags official

Until now, only project maintainers could make a tag an official bug tag.  Now bug supervisors have this ability, too.

Bug 664096, Fix Released should be locked against reopening

Bug supervisors waste time when they have to fix the status of a bug that had been marked fixed but later changed by someone else who mistakenly thinks they have the same bug or has the same problem in an older release.  The option to change a fixed bug to another status is now limited to bug supervisors.

There’s even more goodness to come as we get close to daily updates of Launchpad.  Stay tuned!

Launchpad’s code hosting will be offline from 11.00 UTC for 15 minutes on Friday the 29th October 2010 for hardware maintenance.

During this time you will be unable to push to or pull from code hosted on Launchpad. Code imports will be paused.

Goes offline: 11.00 UTC 29th October 2010
Expected back by: 11.15 UTC 29th October 2010

I recently sent out an email to Launchpad users who had selected the “expire incomplete bug reports” option for their project, explaining that we would be enabling this feature again in Launchpad. Well, actually, I sent out a lot of emails. This happened partly due to poor design of the script I wrote to send the emails and partly due to my own error. I am sorry for the inconvenience this may have caused anyone. We are taking steps to ensure this sort of poorly executed mass emailing doesn’t happen again on Launchpad.

For those who haven’t heard, the rest of this blog post is meant to fill you in on the coming changes.

What is about to change?

Launchpad has always advertised that we auto-expire incomplete bugs matching certain conditions, but we haven’t done this for awhile now.  We are ready to turn this feature back on.  This means that bugs that are considered inactive will have their status automatically changed from Incomplete to Expired.  For more detail on how Launchpad determines if a bug is inactive, visit our Bug Expiry help page.

This change will take effect in about two weeks, sometime during the week of 18 October 2010.

What this means to you?

If you maintain a project in Launchpad and you want this feature, you need to ensure that the Expire “Incomplete” bug reports when they become inactive option is selected for your project on it’s Configure bug tracker page.  We have disabled it for all projects since it has been selected by default but inactive up until now. Sometime before the week of 18 October, you’ll need to re-enable this option if you want to take advantage of automatic bug expiry.

If you maintain a project in Launchpad and you do not want this feature, you do not have to do anything.

For maintainers of Ubuntu packages in Launchpad, we have left this option enabled. Getting this feature re-enabled was driven largely by requests from Ubuntu developers, so we have not changed the config options for Ubuntu packages in Launchpad.

If you have any other questions about this, feel free to leave a comment here or contact me on Launchpad.