0

Code hosting offline 12.00-12.20 UTC 26th January 2011

Published by Jonathan Lange January 25, 2011 in Notifications

Launchpad code hosting will be offline between 12.00 and 12.20 UTC for hardware maintenance on Wednesday, January 26. That’s tomorrow. This means you will be unable to push to, pull from or browse code hosted on Launchpad. All other Launchpad services will be unaffected.

Offline: 12.00 UTC 26th January 2011
Expected back by: 12.20 UTC 26th January 2011

We’ll update this post and our status feeds as soon as we’re back online.

On Friday, our codehosting server went offline unexpectedly. Turns out this was due to a hardware failure. Tomorrow, we will be fixing the underlying hardware problem, but that will mean more downtime. Sorry.

Update: The hardware upgrade went well, code hosting is back online.

1

code hosting offline

Published by Martin Pool January 21, 2011 in General

Due to a hardware failure, bazaar.launchpad.net is offline at the moment. We expect it will be back up and working correctly in about an hour or two from now. (That is, by about 17:00 UTC on the 21st of January.)

This affects all bzr-branch-related services: ssh and http access to branches, and also browsing of branches.

If you saw an “incorrect data check” error or similar from bzr while branching from Launchpad, this is probably the reason why, and the problem should be fixed soon.

Update: Code hosting is now back online. We’re sorry for the inconvenience.

4

Team polls restored, but future is unclear

Published by Curtis Hovey January 11, 2011 in General

We restored team polls because several Ubuntu teams require their use in their charter. They cannot easily switch to another service because it is not possible to organise the members to vote. We decided that to restore them while we decide what to do.

Option one: Contributors re-invent the UI so that setting up a poll is uncomplicated by silly restrictions and requirements. Many teams are not using Launchpad because they want condorcet polls. Launchpad may require them to keep the feature.

Option two: provide the information teams need to use another poll service. Team members can hide their email addresses, so it is not possible for the team admins to gather the member information to setup a poll. Honouring member privacy may require choosing or setting up a poll service that uses OpenId.

There is an unstated issue that options one and two do not address. It is also not possible to contact every member of team in Launchpad. How do team members ever know when a team admin creates a poll? Regardless of if the poll is in Launchpad, or in another service, members are unlikely to participate unless they happen to see the poll while visiting the team page in Launchpad. How often does that happen? Why would I visit my team’s page? I visit the teams I admin because I review membership proposals, moderate list mail and check on PPAs. I have no reason to visit the page of a team that I am just a member of.

3

Tracking PPA download statistics

Published by Julian Edwards in API, Cool new stuff, PPA

An long-requested feature in Launchpad is to let people see who’s using a PPA. Finally, we’ve implemented this!

Initially, the stats are only available on Launchpad’s webservice API. but we aim to show something useful in the web UI at some point.

If you are already familiar with the webservice API, then you can use the following binary_package_publishing_history object methods to retrieve the information:

Fabien Tassin is already using the stats to see how many people are using his daily build PPAs, and wrote an interesting blog post about it.

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.

Previous Entries
Next Entries