0

Launchpad read-only 23.00 UTC 12th January 2011

Published by Matthew Revell January 5, 2011 in Notifications

Launchpad’s web interface will be read-only, with other aspects offline, for around 90 minutes from 23.00 UTC on the 12th January 2011.

Starts: 23.00 UTC 12th January 2011
Expected to be back to normal by: 00.30 UTC 13th January 2011

This is to allow for an update to the structure of Launchpad’s database as part of our monthly release process.

2

Removing team polls

Published by Brad Crittenden December 17, 2010 in Coming changes

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

0

Bug Jam 2010: end of week 1 report

Published by Matthew Revell in General

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:

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

2

Changing how we track Launchpad’s bugs, questions and blueprints

Published by Francis J. Lacoste December 15, 2010 in General

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:

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:

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.

4

Launchpad status info survey results

Published by Matthew Revell December 8, 2010 in General

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:

Method Percentage
The Launchpad blog 38.5%
Identica or Twitter 35.3%
launchpad-users mailing list 15.6%
IRC 8.2%
Facebook 2.5%

How people access Launchpad status information now

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.

Method Percentage
Identica or Twitter 34%
RSS/blog 23.1%
Email 14.3%
Status page or message in Launchpad itself 11%
iCal 2.2%
SMS 2.2%
Other 13.2%

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:

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

Localised disruptions:

Widespread disruptions:

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.

0

Launchpad read-only 10.00 UTC 8th December 2010

Published by Matthew Revell December 1, 2010 in Notifications

Launchpad’s web interface will be read-only, with other aspects offline, for up to 90 minutes from 10.00 UTC on the 8th December.

Starts: 10.00 UTC 8th December 2010.
Expected back by: 11.30 UTC 8th December 2010.

During this time we will be making updates to Launchpad’s database.

5

How do you want to get Launchpad service status updates?

Published by Matthew Revell November 30, 2010 in General

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 🙂

6

Launchpad edge site deprecated

Published by Robert Collins November 24, 2010 in General

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

0

New featured projects on the front page

Published by Matthew Revell November 12, 2010 in General

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.

2

Launchpad Bug Jam December 2010

Published by Matthew Revell November 9, 2010 in General

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.

Previous Entries
Next Entries