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.

1

Commenting on questions

Published by Gavin Panella October 30, 2009 in Cool new stuff

If you’re using edge, you can now just comment on a question in Launchpad. For all questions on Answers, the “Just Add a Comment” button is now always visible.

The new buttons!

Previously, you might have only seen “Add Answer” and “Add Information Request” (or others; the exact buttons vary), both of which add a comment and cause the question status to change. But often, for example, all you want to do is clarify an earlier comment, add some detail, or give a progress update. For that, “Just Add a Comment”.

It’s been put at the rightmost position of all the buttons because we think it should be the least used option. Normally it’s appropriate to use one of the other buttons to move the workflow forward.

The button will land in production with the 3.1.10 release next week.

1

Accessing Git, Subversion and Mercurial from Bazaar

Published by Jelmer Vernooij October 29, 2009 in Bazaar

bzr-svn, bzr-git and bzr-hg are plugins for bzr that make Subversion, Git and Mercurial branches first class citizens in the Bazaar world by allowing you to access them in the same way that you would access native Bazaar branches.

Bazaar has supported multiple file formats from its early days. Both its model and its implementation allow this:

This has made it easy to introduce better and experimental repository formats without having to break old repositories or render them unusable for previous versions of Bazaar by forcing upgrades. Initially new formats were introduced at a very high pace (perhaps even a too high pace?), but fortunately this has slowed down nowadays: the last default format change before the 2.0 release was in 2007.

Having grown interested in Bazaar through Martin‘s talk at Linux.Conf.Au 2005 and his blog posts I started looking into Bazaar in 2005. Since Samba (the main FOSS project I work on) had just switched to Subversion, I was interested in ways to interact with Subversion using Bazaar, in particular so I could do off-line commits. On the Bazaar wiki Aaron had suggested implementing the well defined interface for repository formats for other version control systems (such as Subversion) as well. This sounded very neat, so I decided to see how far I could get and looked into learning Python and becoming more familiar with the Bazaar API.

Now, four years later, 700 bug reports and about 4400 revisions later, we have released bzr-svn 1.0. The models of Subversion and Bazaar have significant differences, and bzr-svn has to take care of mapping between the semantics of both. Perhaps the best example of this is the fact that a Subversion repository is basically a versioned filesystem; there may be some directories that are commonly used as containers for branches or tags, but there are a lot of exceptions to this convention. In Bazaar on the other hand, a branch is a primary object.

In 2006 Rob and Aaron created a simple plugin for accessing local Git repositories in 2006 called bzr-git. Originally it was based on “stgit”, a tool which (among other things) exposed a Python wrapper around the git executables. Following a switch from Samba to Git I took over in 2008 and changed bzr-git to use a new native implementation of Git in Python, based on a project by James. bzr-git now supports accessing remote repositories, working trees and merging changes back into Git.

At the moment I am working on the bzr-hg plugin, again based on an initial proof of concept by Rob. Last month ago the first version (0.1) was released, providing sufficient support for cloning local and remote Mercurial repositories and accessing working trees. There are still some problems to work out — memory usage is excessive, commit and push do not yet work — but there should be a stable plugin in a few months.

0

Meet Francis Lacoste

Published by Matthew Revell October 28, 2009 in Meet the devs

Francis LacosteFrancis Lacoste recently started on a six-month stint of running the Canonical Launchpad team. It seemed like a good time to find out a little more about him.

Matthew: How did you get into free software?

Francis: It was 1996, with a few friends at university, we started an online cinema magazine and) I developed the first generation of the content management system for the site. I was looking to develop this as a “free for non-commercial use” software. Since my Mac at the time kept crashing (Internet and Apple didn’t worked well), I looked into mklinux which was a Linux variant for Powermac. And then I stumbled upon the GNU Manifesto. This made so much sense to me, that I ditched the “free for non-commercial use” and became a GNU head.

Matthew: What’s more important? Principle or pragmatism?

Francis: What is more important, water or air? This is a false dichotomy. You need principles because otherwise your actions are meaningless, at the same time if your principles cannot be applied, cannot drive to action, then your principles are just wishful thinking. The beauty of this interrelation is that you can start anywhere and find the whole. Start at action, ask yourself what are the principles behind it and then you discover more actions you could make to be more effective. Or you can start at principles and then ask yourself how to apply them which will bring more insights as to some way to improve your principles.

Matthew: Do you/have you contribute(d) to any free software projects?

Francis: Not much since joining Canonical (and having a kid). I still receive emails for perl (sic) modules I developed eons ago. I also worked for a few years on the LogReport project. I also met future-Canonical-colleague Martin Pool on the first implementation of what was to become the Apache Java project. Specifically, I updated the mod_jserv implementation to support the Java 1.1 Servlet specification.

Of course, now that Launchpad is open-source, I do daily contributions to open-source :-p (actually, that’s not even true as my responsibilities don’t leave me a lot of time to code — but contributions is more than just code).

Matthew: Tell us something really cool about Launchpad that not enough people know about.

Francis: Launchpad Answers is a really easy way to build community support around your project. (Full disclosure, that was the app I was responsible for when I joined the Launchpad project.)

Matthew: In the Principia Discordia, Malaclypse the Younger states that all things happen in fives. What five things are coming soon in Launchpad that you’re most excited about?

Francis: 1. In September, we defined a strategic vision for Launchpad around “bridging the gap between upstreams and the Ubuntu distribution”. This will help us to develop a much more focused application.

The current set of features related to the strategic focus you can expect are:

2. Forwarding of triaged bugs from Ubuntu to the upstream bug tracker.

3. Daily Ubuntu packages of upstream tip.

4. Sharing of translations between upstreams tip and the Ubuntu source packages.

5. Zero OOPS Policy. This means rooting out all time outs and errors.

Matthew: Okay, Kiko’s special question! You’re at your computer, you reach for your wallet: what are you most likely to be doing?

Francis: Ordering books on amazon.ca. Although by now, I don’t need to reach for my wallet for this.

Matthew: Thanks Francis!

Photo of Francis Lacoste by Simon Law, CC-BY-SA, published on Flickr.

0

Launchpad offline 04.00 – 04.30 UTC 26th October

Published by Matthew Revell October 23, 2009 in Notifications

Launchpad will be offline for roughly 30 minutes from 04.00 UTC on Monday the 26th October 2009 for database maintenance.

Going offline: 04.00 UTC 26th October
Expected back: 04.30 UTC 26th October

Previous Entries
Next Entries