launchpadblog

Glyph posted an interesting script to the launchpad-users mailing list that I thought was definitely worth sharing:

Quite often, I’ve discovered that I want to add someone (who already has an account on launchpad) to my system so they can log in and attach to my ‘screen’ session; however, I will inevitably screw up typing in the finger information, setting permissions on their .ssh directory, assigning them a bogus password, etc. Here’s a simple Python script that will add a user to your system with the same username as on Launchpad, and with their SSH keys already set up so they can log in, but no system password.

You can download the script from http://people.ubuntu.com/~kiko/launchpadduser.py.

It requires adduser, wget and python. You’re expected to run this as root, so the usual warnings apply, but it’s simple enough for you to audit on your own. And there is no error handling! A usage example:

root@beetle:~# python launchpadduser.py kiko
Adding user `kiko' ...
Adding new user `kiko' (1012) with group `users' ...
Creating home directory `/home/kiko' ...
Copying files from `/etc/skel' ...
--09:43:36--  https://launchpad.net/~kiko/+sshkeys
           => `/home/kiko/.ssh/authorized_keys'
Resolving launchpad.net... 91.189.90.211
Connecting to launchpad.net|91.189.90.211|:443... connected.
HTTP request sent, awaiting response... 200 Ok
Length: 860 [text/plain]

100%[=============================================>] 860           --.--K/s             

09:43:38 (9.49 MB/s) - `/home/kiko/.ssh/authorized_keys' saved [860/860]

And presto:

kiko@anthem:~$ ssh beetle
Linux beetle 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686
kiko@beetle:~$ 

Launchpad is kinda hard to describe. When I’m asked what it is, I normally use three or more of the words “open source free software support project Q&A code registration bugs management listing bazaar planning hosting”. Most people make comparisons to Sourceforge, Savannah, Berlios and Google code hosting, and while those are useful, it’s only a part of the picture. The other part, which is perhaps not as well understood, is that it’s also a public project registration service, similar to Freshmeat. Well, except for a twist.

Launchpad’s source code directory

In addition to providing a project registration service open to the public for free (with probably the best Google juice out there; this has caught some people off-guard before!), Launchpad takes this to a next step, and actually provides a unified interface for interacting with each project registered. The most obvious unified service that you can use today is our code directory, which I want to introduce here.

Now Launchpad provides some key features related to source code for free software projects:

• Project registration: you can register any free software project on Launchpad (and separately, of course, have it hosted here — if you own it and want to).
• Bazaar hosting: you can host Bazaar branches for any project, and you can fetch code using the bzr client.
• Code imports: we allow you to request code imports for any externally-hosted project that uses CVS or Subversion.

There’s a really cool thing that falls out of the combination of code imports, branch mirrors and Bazaar: you can use bzr and Launchpad to fetch any piece of software we have registered code for. And Bazaar even provides a little shortcut that makes it even easier to grab the default branch for any project: bzr branch lp:<projectname>.

An open source supermarket

The effect is that you can, right now, pull a /lot/ of software in less than 30 keystrokes, without knowing or caring about what its native version-control system is, or where it’s hosted. Want to grab the Python source code? Just do bzr branch lp:python. How about Storm? bzr branch lp:storm. In fact, there are thousands of native Bazaar branches and over one thousand imported branches. Here are just a few examples of major projects you can pull right now:

• Ruby on Rails:
  bzr branch lp:rails
• Blender:
  bzr branch lp:blender
• F-Spot:
  bzr branch lp:f-spot
• Grub:
  bzr branch lp:grub
• Twisted:
  bzr branch lp:twisted
• Bazaar itself:
  bzr branch lp:bzr
• GCC:
  bzr branch lp:gcc

Couldn’t find a branch listed for the project you want? We can sort this out for you, too. If it’s in CVS or Subversion elsewhere, you can just follow the instructions for setting up an import. If it’s a Bazaar branch, just register it and we’ll hook it up with the project’s mainline series record.

More on project branches

If you visit https://code.launchpad.net/ you’ll notice that it has an abbreviated project cloud, which lists all the projects with branches in Launchpad. The project’s name is rendered in different sizes and intensities according to how active the actual project is; the size of the name in the cloud is defined by the number of branches that the project has, and the intensity of the tag in the cloud is determined by how recent the last commit to any active branch is. And green indicates that there’s a default branch for the project, which means that the bzr branch lp:foo abbreviation works for it. There’s a also a page with the full code cloud.

So each of those projects has active source code branches that you can pull from Launchpad using Bazaar. For instance, to check the source code for Apport, you could click on its entry in the listing and getting there you could inspect the branches available and select one of them for pulling. For instance, if you chose Will Woods’ Fedora support branch you get instructions on how to pull it: bzr branch http://bazaar.launchpad.net/~wwoods/apport/fedora or even just
bzr branch lp:~wwoods/apport/fedora

Imports and today’s deliveries

Import requests are handled in a queue by Launchpad code ninjas; normally this it Michael Hudson’s responsibility but starting today I’ll be helping out too. Of the import requests I handled today, the following succeeded and are ready for grabbing in the great bzr-get-lp-colon fashion:

• bzr branch lp:gtk-qt-engine
• bzr branch lp:lshw
• bzr branch lp:tsclient
• bzr branch lp:dohickey
• bzr branch lp:meshlab
• bzr branch lp:rasmol

I’ll keep you posted on new imports as they come online. Meanwhile, go grab some branches and post some comments telling me what you think. If you have any problems or questions about our code hosting service, feel free to ask on the Launchpad code section in answers.launchpad.net.

This past week’s Bug Janitor thread has made it clear that we need better descriptions of what our bug statuses actually mean. While it’s true that many project teams have organically grown their own semantics for Launchpad’s bug statuses, it’s important that there be a large degree of understanding of them between community and Launchpad developers — we want to develop features that make sense, and if you don’t know what we think the statuses means, that becomes a lot harder!

Launchpad currently offers 9 different statuses for bugs. 6 of them model the development workflow from bug report to fix released:

1. New (a.k.a. Nobody Has Looked At Me Yet)

   A bug starts out its life as a New bug. A bug in this status is one which still needs to be evaluated by a triager (essentially, somebody clueful enough about the project to decide whether it’s a bug or not); it is not acknowledged as a bug yet.

   In Bugzilla, this status is called Unconfirmed. In most Trac and Mantis instances this this status is also called New. It is the zero-state of all bugs!
2. Incomplete (Reporter, Give Us More Information!)

   This is the status around which the Bug Janitor’s expiration code works. It is an intermediate stage between New and Confirmed; it means that someone has looked at the bug, attempted to understand or reproduce it, and needs more information to be able to confirm it is in fact a bug.

   Once additional information has been added, the bug is meant to be reviewed and either more information is requested — again, via the Incomplete status — or the bug is marked Confirmed, Invalid or Won’t fix. To review bugs in Ubuntu that are Incomplete which have new information, you would use this report, which uses the “Incomplete (with response)” option in Ubuntu’s advanced bug search form.

   Incomplete is a temporary status: it is intended to be a stepping stone from New to Confirmed that is managed by an active QA team. Bugs aren’t meant to stay here forever, and the Janitor script is meant to enforce that useful semantic: either more information is made available or the bug is closed for lack of information. Of course, the bug can always be reopened or reported again by someone with a better understanding of the symptoms.

   In GNOME’s Bugzilla this is called NEEDSINFO. In fact, in a previous incarnation Launchpad used the same term (Needs Info) for this status, which poorly communicated the fact that it preceded the Confirmed status, and which made it ambiguous: it ended up being used whenever the bug was blocked on missing information. The truth is that the bug can in many situations be blocked on missing information, but Incomplete is meant for the specific gap between New and Confirmed.
3. Confirmed (Oh-Oh He’s Right It’s Broken)

   This means that in fact the bug has been confirmed and exists. QA are meant to mark the bug confirmed only when they have enough information to reproduce the bug or trivially establish that it is in fact something that a developer needs to look at.

   This status is particularly important because from this point onwards, developers will interact much more intensely with the bug; the more information gathered at this point, the better.
4. Triaged (Keep This Bug On The Radar)

   This is an intermediate status that can be used to distinguish community-confirmed bugs from bugs that the official QA team has acknowledged and plans on working on. Many projects don’t need a separate stepping stone and developers can pick bugs directly from Confirmed into In Progress. At this point, we are sure that a) the bug has been reproduced and established b) developers have acknowledged.

   If you are an upstream project and you don’t find the Triaged status useful, please let me know. I want to collect information to determine whether any projects find it useful in order to better adapt the UI to it.
5. In Progress (I Started Working On It!)

   Once all the relevant information has been collected, a developer marks the bug In Progress. This status is practically always set by the developer himself, indicating that he has already started the analysis and coding work towards fixing it.

   This is an exciting status and in general, bugs should not last too long (or get stuck) here. If they get stuck here, chances are that the developer has given up on the bug (in which case it should be moved back to Triaged or Confirmed), or that he has started and stopped work on it (in which case he needs help to get it unblocked).
6. Fix Committed (Please Test My Fix)

   This is a special status that indicates that the developer has produced a working fix and has committed it to revision control.
   In a way this is a status geared towards projects that use RCS extensively, but generally speaking OSS projects do use RCS and do commit bug fixes to revision control as part of the bug fix process.

   The qualified definition for this status is that while a fix does exist (and in projects with code review, that it has been accepted by the official project team) it has not been made available in a version released to the general public.

   For distribution packages, this status is intended to communicate that the developer has produced a fix in a location other than the official Ubuntu archive; in Ubuntu, for instance, in a bzr branch of the package, or as an upload in a PPA or ubuntu-proposed.
7. Fix Released (This Revolution Is Over!)

   This status is meant to communicate that the bug fix has been made available in a released form to the general public. The key meaning of this status is public availability; end-users can expect to download or access an updated version of the software that contains the change.

   In the case of Ubuntu, bugs are automatically marked Fix Released when sources are uploaded to the official Ubuntu archive. This is an approximation, given that the source may fail to compile, but it is a simpler workflow which works well.

There are two additional statuses that are used to capture reports that have been rejected:

8. Invalid: This status is synonymous with “Not a valid bug”. There are many reasons a bug might not be valid: if it was deemed to be user error, or if there was not enough information to establish whether it was a bug or not. The reporter might be asking a question, testing (or joking). The actual project it was reported against might have been dismantled and abandoned. Invalid is meant to catch all the cases where the reporter’s request is best handled in a different form, or not at all.
9. Won’t Fix: This status is only meant to be used by official project members. It is a statement that confirms that a problem exists, but that no work will be done towards fixing it. Perhaps it’s a controversial issue upon which an official decision has been issued, or it’s something that is better addressed in a different way, or fixed in another software component. It is often used in association with release targeting to specify that a bug will not be fixed in that release.

From the above, you will notice that the bug workflow in Launchpad is pretty linear, traversing from New to Fix Released (or one of the two Rejected statuses). Of course, this traversal can take a long time depending on the availability of information and resources, but there are no major forks in line.

Access Restrictions

For the most part, Launchpad is liberal as to who can set bugs to a status; we would rather allow people to help garden the bug statuses than force them to ask permission to do so. There are two statuses, however, which are restricted to the project’s bug contacts and registrant: Won’t Fix, and Triaged.

• Won’t Fix is restricted for a very specific reason: it is intended to represent an official denial, and therefore should really only be pronounced by a member of the project.
• Triaged is restricted because it intends to capture confirmation by an accredited QA person who has verified that enough information has now been gathered about the issue that it can go straight into a developer’s work queue.

Project registrants can set up bug contacts by using the “Change bug contact” link on their bugs.launchpad.net project page. Bug contacts get notifications of all bug changes in a project; if that’s overwhelming, you can use our X-Launchpad header family to filter things in your mail client.

Thanks

This is my first posting on bug statuses. My next posting will talk about concrete situations in the bug tracker, focusing on corner cases (such as “what do I do when this bug report has already been fixed by an unrelated change?”); help me out by adding comments that describe situations which you are unsure of and I’ll consider them in my article. Thanks!