0

Read-only 22.00-23.00 UTC 16th December 2009

Published by Matthew Revell December 10, 2009 in Notifications

Launchpad’s web interface will be read-only from 22.00 UTC on Wednesday the 16th December 2009 for the release of Launchpad 3.1.12. During that time, other services including PPAs, code hosting and the email interface, will be offline.

Starts: 22.00 UTC 16th December
Expected back: 23.00 UTC 16th December

This is the final Launchpad code release of 2009! We’ll post the 2010 release calendar here in the next few days.

Follow Launchpad’s official status feed for full status information.

2

Inline dupe-finding: an exercise in pain reduction

Published by Graham Binns in Bug Tracking, Cool new stuff

For the last million years1 or so I’ve been working on a cool new feature for Launchpad Bugs: an inline, AJAXified, asynchronous dupe finder.

For quite some time now people have encountered timeouts or long response times when trying to file bugs, particularly when they enter a long bug summary or the project that they’re filing the bugs on has a lot of bugs through which Launchpad has to search in order to be able to find possible duplicates. The upshot was that whenever a timeout occurred people were unable to file a bug and would have to back up and start again. Needless to say, this was frustrating for all involved.

The new inline dupefinder, which you’ll now find on the “Report a bug” page of any project in Launchpad (when viewed on edge.launchpad.net) is designed to stop this from being a problem, or at least to reduce the problem to a more manageable level and stop it from getting in peoples’ way. It does this in two ways:

  1. The inline list of duplicates is much quicker to render than a full Launchpad page.
  2. If the search for duplicates times out for some reason you’ll still be able to file a bug.

Here’s the catch: we need your help. Launchpad’s development cycle this month is very short due to the approaching year-end holiday period, so we need to get as much testing done on this as possible. Check out the dupe finder, see if it works for you and, most importantly, report a bug if it doesn’t.

One last thing: at the time of writing, the inline dupe finder only works for projects (like Launchpad Bugs), not for packages or project groups. We’ll hopefully be enabling it for project groups today and with a bit of luck for packages, too. We started off with projects only because it’s the simplest implementation of the concept and it gives us a good base to test from.

Thanks in advance for your help. Let’s make Launchpad awesome together!

1 This might be an exaggeration.

1

Phone interviews about your Launchpad usage

Published by Matthew Revell December 8, 2009 in General

In the Canonical Launchpad team, we all use Launchpad every day. As you’d expect, we also have a lot of contact with people who use Launchpad, both for Ubuntu and other projects.

While personal experience of Launchpad and informal contact give us an insight into how some people use Launchpad and what developments we can introduce to help people do more, we want to cast the net wider.

That’s why, at last month’s Ubuntu Developer Summit in Dallas, I kicked off a new series of Launchpad user interviews.

The next set of interviews will be by phone, later this month, and I’d like to invite you to take part. It’ll take between 30 minutes and one hour and I’ll pay for the call 🙂 During the conversation, I’ll ask you some straightforward questions about how you use Launchpad.

Right now, I’m mostly looking for people who act as a bridge between Ubuntu and an upstream project. For example, you may work on an upstream project (whether or not it uses Launchpad isn’t important) and you occasionally check Launchpad to see what bugs Ubuntu users have filed against that project as it is packaged in Ubuntu. Or maybe you translate both for an upstream project and you work on translations for the project’s Ubuntu package.

That’s not a strict requirement, though: I’m interested in hearing from everyone who wants to talk about their Launchpad usage.

If you’re interested, send me an email (my first name dot my last name at canonical dot com) with a brief description of what you use Launchpad for and I’ll choose ten people for this initial set of phone interviews. Also, let me know your availability for a phone call.

0

Read-only 22.00-23.30 UTC December 3rd

Published by Matthew Revell December 3, 2009 in Notifications

Launchpad’s web interface will be read-only for 90 minutes from 22.00 UTC December 3rd. At that time, all other Launchpad services — including PPAs, bug mail and code hosting — will be unavailable.

Starts: 22.00 UTC 3rd December
Expected back: 23.30 UTC 3rd December

I’m sorry that we’ve had to disrupt your service twice in two days and for the short notice of this coming interruption. During our December 2nd code release we encountered some problems and decided to delay the roll-out in order to resolve them.

You can stay up to date with Launchpad system status by following our identica account.

4

Getting the most from bug mail

Published by Matthew Revell December 2, 2009 in Bug Tracking

If you’ve reported, commented on or subscribed to a bug in Launchpad, you’ll have seen Launchpad’s bug mail. It’s probably the easiest way to stay up to date with the bugs that interest you and there are a few things you can do to get the most out of it.

If you don’t read anything else…

Probably the best thing you can do to make bug mail useful is to ensure you only get the bug mail that interests you.

Launchpad makes the reasonable assumption that, if you report, comment on or subscribe to a bug, you’re interested in that bug. So, it’ll send you email updates when:

* someone changes the status, importance or targeting of the bug
* someone makes a comment on the bug.

If you find you’re no longer interested in a particular bug, check for an unsubscribe link in the footer of the bug mail. You can also visit your own bug page to check which individual bugs you’re subscribed to.

If you don’t see an unsubscribe link, it means that you’re not subscribed directly. Instead, you’re receiving the bug mail because either:

So, what do you do?

You’re subscribed to all bugs associated with a distro or project

At the bottom of the bug mail is a link to the bug’s page in Launchpad, along with a short explanation as to why you’re receiving the bug mail. If you’re subscribed to all the bugs associated with Launchpad, for example, it might say:

You received this bug notification because you are subscribed to Launchpad itself

These bulk subscriptions do not show up on your bug page. Instead, you need to visit the distro, project or series’ bug page and follow the Subscribe to bug mail link, where you’ll be able to unsubscribe.

A team you’re in is subscribed to the bug

Similarly, if you’re subscribed to a bug indirectly through your membership of a team, the bug mail footer message will tell you which team. You now have two options to stop receiving the bug mail:

Of course, there is another way that isn’t as drastic as either of those two options: instead of unsubscribing, filter the bug mail to a dedicated folder.

Filtering bug mail

Most mail clients can filter your incoming mail based on certain elements, such as text in the subject line, certain mail headers and so on. Launchpad makes it easy to filter bug mail.

The most obvious thing you can use to filter your bug mail is the subject line: Launchpad adds the bug number to the start of each bug mails subject, such as:

[Bug 123456] Add some whatsits to the doodah

The footer, which explains the reason for your receiving the bug mail, can also be handy. Similarly, Launchpad adds an X-Launchpad-Message-Rationale: header to each bug mail, which you can use to filter the bug mail.

Matt Nuzum wrote an excellent guide to filtering Launchpad bug mail. It’s aimed at Gmail users but you can tailor it to your own mail client.

Duplicate bugs

If you’re subscribed to bug A and someone marks bug A as a duplicate of bug B, Launchpad automatically subscribes you to bug B. You can always follow the unsubscribe link in the mail footer.

Two-way bug communication

Before I go, I should mention that bug mail is not just a one-way conversation. You can report, comment on and alter bugs entirely by email. It’s quick and really easy. Take a look at our guide.

Don’t forget that if you reply to bug mail, your entire email will be published as a public bug comment on Launchpad. So, remove those phone numbers from your email signature if you don’t want them to be public!

0

Launchpad read-only 22.00 UTC 2nd December 2009

Published by Matthew Revell November 30, 2009 in Notifications

Launchpad’s web interface will be read-only for roughly 90 minutes from 22.00 UTC on Wednesday the 2nd of December 2009. Other aspects of Launchpad — including code hosting, PPAs, the API and email interface — will be unavailable during that time.

Starts: 22.00 UTC 2nd December 2009
Expected back: 23.30 UTC 2nd December 2009

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

The next planned down-time for Launchpad will be for our 3.1.12 release on the 16th December. 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. We’ll be publishing the 2010 calendar soon.

0

Code hosting and browsing offline 13.00-17.00 UTC 19th November

Published by Matthew Revell November 17, 2009 in Notifications

We’re upgrading the disk space available for Launchpad’s code hosting! During the upgrade, we’ll have to take code hosting and browsing offline.

Going offline: 08.00 UTC Thursday 19th November
Expected back: 12.00 UTC Thursday 19th November

We’re sorry that you’ll be unable to browse, push to or pull from code hosted by Launchpad during this time.

You can stay up to date using Launchpad’s official system status feed (Twitter version).

UPDATE: We’ve updated the time of the down-time. It is now 08.00-12.00 UTC.

0

November Lazr-js Sprint Report

Published by Paul Hummer in General

Last week, members of the Launchpad team got together with members of other teams across Canonical to sprint on lazr-js.  lazr-js is the library the Launchpad team created on top of the Yahoo User Interface 3.0 javascript library to provide a richer user experience.  For instance, the “widgets” in lazr-js are used in bug pages to help users change bug status and importance without leaving the bug page, and allowing users to subscribe to a branch without leaving the branch page.

One of the big things we focused on with lazr-js last week was integration into apps other than Launchpad.  We worked with members of the internal Canonical webapp teams, the Ubuntu One team, and the Landscape team to get lazr-js integrated into those apps, and find the issues that anyone would have while trying to integrate lazr-js into their own app.

As we focused on integration, we were able to see where we could make lazr-js more generic and easier to use.  We were able to find ways to automate the tests we have written for the code in lazr-js.  We also focused on fixing the bugs in lazr-js that would prevent Internet Explorer users from benefiting from lazr-js enhancements to an application, but we still have much to do in the way of cross-browser compatibility.  We’ll be working towards browser compatibility in the next few months, and welcome any contributions from the community.

The sprint was a huge success.  At the beginning of the week, lazr-js was a Launchpad library, and at the end, it became a library that can be used by anyone that wants to have a rich browser experience for their webapp.

0

Ibid chat bot

Published by Matthew Revell November 9, 2009 in Projects

Chat bots can be controversial. Apart from the fun to be had watching a friend carrying out an inadvertent Turing test, finding the right balance between useful information and annoyance seems to be one of the harder aspects of chatbotology.

I spoke to Jonathan Hitchcock, Michael Gorven and Stefano Rivera about their work on the Ibid chat bot.

Matthew: What are you doing with Ibid that’s different to other chat bots?

Ibid team: Like all bots, Ibid has two parts: the front end, and the back end, and we like to think that there is something to distinguish Ibid in both.

On the front end, we attempt to make the bot as intuitive as possible to interact with. All commands are natural language, and our philosophy is that the plugins should try to work out what the user actually wants to know and answer that, rather than forcing him/her to learn an esoteric set of syntax before he can use the bot. Queries are bubbled through plugins in order of priority so that the most relevant reply can be given.

Secondly, on the back end, Ibid is also divided into two parts: “sources” (i.e. transports, communication mediums – IRC, jabber, email, etc) and “plugins” (modules that tell the bot how to respond to various queries). The design aims to be clean and modular: all sources and plugins are discrete units that can be enabled or disabled without breaking any assumptions elsewhere in the code. Unlike other bots where non-IRC protocol support seems to be an afterthought, Ibid plugins deal with all protocols equally (hopefully without making them all equally bad).

This modularity helps both new and existing developers. It is easy to jump straight into a small part of the code without having to understand the entire system. It is also very easy to add new sources: we had a DC chat source up and running in under a day, and a prototype GSM SMS gateway in a weekend. In addition, hot-pluggability is an important goal of the project: you can add and remove plugins and sources on the fly, without having to restart the bot.

Matthew: Who do you see using Ibid?

Ibid team: As we’ve been developing the bot, we’ve started thinking in terms of three different personas: users, owners and developers.

Users are the end-users who happen to be in IM channels where an Ibid is running — they should just see the bot as a fun and useful tool. They’ll notice people using it to google things, store factoids, check the weather, do currency conversions, and so on, and start following suit. We’ve noticed that our bots very quickly become integral to channel communities, and we try to make sure the bot’s “personality” facilitates this: the natural language interface, and the characteristic responses that the bot gives aid this. Michael and Jonathan both have Ibid instances running internally at their companies, and the other employees find them very useful.

Owners are the people that run instances of the bot — they probably run the channels too, and they need a way to integrate other things with IM. Ibid aims to make that easy. We’ve already got plugins for checking RSS feeds, working out distances, fetching tweets, and so on — the plugin nature of the bot’s features mean that as soon as a new need arises, we can churn out some code to fulfill it.

This is where the third persona comes in: the developer. Ibid is designed to have a very low barrier to entry, and to make it very easy to write plugins, so it can be used as a framework for interfacing with almost anything. It already has plugins for interfacing with Bazaar, Trac and Buildbot, and a Launchpad plugin is in development. Because Ibid is so modular, stripping out all the funky stuff to build an IM interface to a single service is pretty simple, and Ibid hopes to be a good building block for such systems. Which brings us to your next question…

Matthew: Are you hoping to attract developers to Ibid?

Ibid team: See here.

That would be a yes. In the channels where we have Ibids running, users have contributed plugins for features they want, and in one case used it as a quick way to get an IRC game up and running. We’d like more of all of those.

We’ve done our best to make it as simple as possible to write Ibid plugins. There’s still some work to go (mostly documentation), but anyone who knows some basic Python should be able to hack a quick plugin together in a very short time.

We haven’t made an initial release yet, as some of the Internal APIs have some biggish problems that need to be resolved, but the bot is packaged and already works out of the box, and we’d love for people to start using it and contributing plugins.

Matthew: The project’s a fairly heavy user of Bazaar. What made you choose Bazaar over other VCSs?

Ibid team: It was almost accidental — we didn’t have much experience with DVCS, but we definitely wanted to use one rather than, say, subversion. We saw that the Ubuntu community was punting Bazaar, which is relatively sane (compared to, say Git), and ran with it. It turned out to be a good choice: it’s simple to learn and pretty powerful. It also has a very low barrier to entry, coming from more traditional VCSs, but you can ramp up to using the advanced features in fairly small, but logical steps (which makes it very similar to python, as a learning language, I suppose).

Matthew: What aspect of Launchpad has most helped your development of Ibid?

Ibid team: We originally started with Launchpad just to get quick bug-tracking integration, but soon discovered the other features on offer. After moving the source over to be wholly hosted on Launchpad, we started to use branches and merge-requests, and these have now become integral to our development methodology. Every feature and fix that we work on is developed in a separate branch and the merge reviewed by all three of us. Waiting for reviews can stagnate development a bit when all the developers are busy with their dayjobs, but we think the results are worth it — apart from the obvious benefits of catching bugs before they’re merged into trunk, the request-and-review process keeps us all involved and aware of what is happening in the project.

I imagine that as we grow, this benefit will lessen (since not everybody will review each merge), but it is still a good way of signalling to the rest of the team that changes are happening in an area, so that if they are interested, they can make their opinions heard before the changes get finalised.

As a whole, the tight Lauchpad-Bazaar integration has been a huge bonus, allowing us to develop from a few guys committing bits of code to trunk into a community with workflows, milestones, goals and a clear vision of where we’re headed. Having the VCS and the bug-tracker and the discussion boards and everything all in one place really builds cohesion in the project.

Matthew: What would you most like to see improved or otherwise changed in Launchpad?

Ibid team: We have been moving more and more of our project management into Launchpad (throwing out Trac, and our own Bazaar repository, and our own mailing lists, and so on), but there are still a few things that we have to host ourselves: repositories for non-Ubuntu packages (just Debian debs right now, but we’d like to include RPMs, etc, in the future), the build environments to create them (we have our own pbuilders presently), documentation, and our wiki.

There are free services that provide each of the above, such as the OpenSUSE build service, and the many “create your own wiki” services, but filling those gaps would mean our project could live entirely on Launchpad, and would bring along greater integration and easier flows.

Other neat things we could use would be support for Bazaar hooks, and permanently linking merge commits with the merge request — currently we include the merge request URL in the commit log.

Basically, tighter integration of everything would make project management much easier, and let us focus more on coding, which is always a win.

Matthew: Thanks Jonathan, Michael and Stefano!

0

Launchpad offline 09.00 – 10.30 UTC 5th November

Published by Matthew Revell November 4, 2009 in Notifications

Launchpad will be offline for a scheduled code release for around 90 minutes from 09.00 UTC on the 5th November.

Going offline: 09.00 UTC 5th November 2009
Expected back: 10.30 UTC 5th November 2009

This is to release version 3.1.10 of Launchpad. We’re sorry for the short notice of this down-time.

Previous Entries
Next Entries