launchpadblog

Some of the Launchpad team will be in Brussels next week for UDS, so it’s a great opportunity to head to a bar and meet up with other Launchpad users 🙂

Come join us at Delirium Café from around 8pm on Wednesday the 12th of May. Look out for the people in Launchpad and Ubuntu t-shirts.

• What: Launchpad meet-up
• Where: Delirium Café, Impasse de la Fidélité, 4A – 1000 Brussels
• When: From around 8pm on Wednesday the 12th of May

Mail me if you have any questions or just to say you’re coming!

Many users have discovered that they could not reuse an email address that once belongs to a team. While Launchpad claimed the contact address was gone, that was not the case; it was hidden, never to be seen again. This is fixed. Launchpad does what it says. It removes the email address. The address can be re-registered if needed.

Many list moderators have noted that there are messages with no content in the moderation queue. This is because the messages had no text part, and that these are spam. Launchpad now discards messages without a text parts. You will not be asked to moderate a message that has no content. There is one caveate to this, content-less messages already in the moderation queue must be removed using the UI.

The Ubuntu packages portlet lists the most recent project packages in Ubuntu’s main archive. But there are thousands of Ubuntu packages that are not linked to a registered Launchpad project. The links are needed to forward bugs upstream, sync translations, and get the latest project code. The portlet now suggests unlinked packages.

You can help Ubuntu and the project by selecting the right package. There are many cases where the project’s name is different from the Ubuntu package, and you can search for an alternate package. You can also state that the project is not packaged in Ubuntu.

After the project is linked to an Ubuntu package, it is possible to link it to other project packages from the All packages page. You can also do this from the project’s series pages.

Update: Have a look at the Gedit Developer Plugins project’s overview page for an example.

Projects get an improved “Get Involved” portlet. This portlet provided links to create projects artefacts like bugs and branches. It was never clear though how to enable these links. Privileged users like project owners will see links to configure Launchpad applications. The portlet also call attention to applications that are not configured.

The first use of the not configured state is the project branch. Contributors cannot submit code if Launchpad does not know the series branch, and most importantly, communities like Ubuntu need access to the project’s focus of development. The new Configure (project|series) branch form allows you to setup an code import and link the branch to the series.

A few links to Launchpad related posts from the past month or so:

• Fixing the bug tracker widget: Curtis Hovey looks at what’s wrong with the way you set a project’s external bug tracker, in Launchpad.
• No project is an island: Curtis again, “I think the best summary of what Launchpad does is that it hosts open source communities.”
• Canonical pays to upgrade Gnome’s Bugzilla: “…the makers of Launchpad paid for improvements to Bugzilla, a competing product—not to mention that Ubuntu’s competitors will benefit from improvements to GNOME. As [Kiko] notes, Canonical views this as ‘bridging the gap’ from Ubuntu to upstream.”
• Microsoft developer Garret Serack announces The Common Opensource Application Publishing Platform (CoApp): “CoApp aims to create a vibrant Open Source ecosystem on Windows by providing the technologies needed to build a complete community-driven Package Management System, along with tools to enable developers to take advantage of features of the Windows platform.” And it’s hosted on Launchpad.
• Being the Launchpad Release Manager: Deryck, the Launchpad Bugs team lead, talks about managing a Launchpad release and asks if it makes sense to talk about website releases.

(This is a correction to a previous post.) Launchpad’s web interface will be read-only for roughly 90 minutes, from 23.00 UTC Wednesday 3rd March to 00.30 UTC Thursday 4th March, 2010. Other aspects of Launchpad — including code hosting, PPAs, the API and email interface — will be unavailable during that time.

Starts: 23.00 UTC, Wednesday 3rd March 2010
Expected back: 00.30 UTC, Thursday 4th March 2010

During this time, we’ll be releasing the code for Launchpad 10.02.

The next planned down-time for Launchpad will be for our 10.03 release on the 31st of March. We’ll publish the exact time, nearer to the release date, on our status page.

You can also see the Launchpad release calendar to check for future release down-time.

Just a quick note to link to some interesting Launchpad-related posts/articles that have cropped up over the past week or so:

• An introduction to collaborative development with Launchpad — (Ars Technica)
• Some thoughts on using the Windmill testing framework in Launchpad development — (Björn Tillenius, via Planet Launchpad)
• Three tips for enhanced productivity — (Julian Edwards, via Planet Launchpad)

If you haven’t seen it yet, take a look at Planet Launchpad.

If you visited Launchpad between 13.30 and 15.30 UTC yesterday (4th Feb), you’ll have seen that Launchpad was largely unavailable.

Since then, I’ve spoken to quite a few people who use Launchpad regularly and I want to say thanks to everyone for your patience while we fixed the problem. As we all use Launchpad for our own development, we know just how painful unplanned down-time is and we’re sorry for the disruption to your work.

I’d like to explain what happened, how we fixed the problem and what we’re doing to avoid a similar situation in future.

As you’d probably expect, we run more than one database server for Launchpad. There are two master databases and then slaves, which are copies of the masters. The master databases replicate constantly to the slaves.

When Launchpad makes a read-only request, such as fetching the title and description of a bug report, we can reduce the load on the master databases by fetching that data from one of the slaves. However, to ensure the data you see is up to date, each time Launchpad is about to fetch data from the slave database, it checks how long it has been since the last replication from the relevant master database. If, for whatever reason, the replication wasn’t recent enough, Launchpad will instead grab the data from the master database.

Yesterday, it was this check that was taking far longer than expected and so causing the problems that you may have seen. We were able to implement a temporary fix, to bring Launchpad back online, by directing all database queries straight to the correct master.

In the longer-term, we’re going to overhaul the way that Launchpad checks the freshness of the data in the slave databases. Rather than checking each time a query is made, Launchpad will check once every so often and cache the result, meaning that this problem shouldn’t arise again.

Thanks again for your patience.

Brad has written a great guide to writing and committing your first code for Launchpad.

Amongst other things, he has a useful bullet list that describes the steps between deciding you want to write code for Launchpad and actually seeing your work in place.

“The steps for fixing a bug or adding a new feature in Launchpad are:

• Find a bug or feature request. The best place to look is on the milestone for the application of interest. (See the list for Launchpad Registry’s 10.02 milestone).
• Research the problem.
• Have a pre-implemention call.
• Grab the latest branch of Launchpad (which we informally call ‘rocketfuel’). You can use ‘rocketfuel-get’ to update your copy of devel and ‘rocketfuel-branch’ to make a branch for your work. It’s best to create a new branch for each chunk of work you do.
• Write your tests, write the code, repeat. (Read about TDD.)
• Push your code to Launchpad (‘bzr push’).
• Create a merge proposal (‘bzr send’).
• Have a review, fix changes, repeat.
• Run the tests. At a minimum you should run all the tests for the application you changed. For bugs you can do that with ‘bin/test -vvm lp.bugs’.
• Submit to PQM.
• QA the change when it lands on edge or staging.
• See the change in production when the next release rolls out.
• Bask in your awesomeness.”

If you want to fix a bug or get a feature into Launchpad, go read Brad’s post.

Now that I have your attention…

We’ve been overwhelmed by the popularity of PPAs on Launchpad. In fact, according to our sysadmins, they are a little too popular and now our disks are full.

Full disks mean no more PPAs, and no more uploads to PPAs. We’d like to add some more disks, but we can’t actually do that soon enough for a bunch of complicated reasons.

Instead, we’ve decided that we’re going to remove all of the source files for any uploads that are:

• in PPAs
• not published, that is, deleted or superseded
• have been not published for over seven days

Note that we already delete the binaries for such uploads.

We are going to delete these old files this Wednesday, January 27th. We’re really sorry that we are announcing it so close to the actual event — we know it’s a hassle.

If you want to keep any of these files, you are going to have to download them right now. Here’s how to do it.

1. Go to your PPA’s web page on Launchpad and click on “View package details”.
2. Change the filter to search for “Any status”. Click “Filter”.
3. For each superseded or deleted upload with files you want to save, expand the upload and manually save all the files under the “Package files” heading.

If it’s a busy PPA like the example one, then there will be a lot of old versions to download. If you aren’t sure, you probably won’t need all of them. Ask on #launchpad on Freenode or the launchpad-users mailing list if you are unsure.