launchpadblog

Launchpad has supported assigning questions to users for several years, but the privilege was limited to project owners. This meant the feature was rarely used. Since the feature was also not visible, answer contacts often requested that we develop the feature. Question listing now include the assignee column. Answer contacts can assign a question to a user via the edit page. The assigned user will receive a notification about the assigned question. An assigned question will never expire; the assignee is obligated to answer the question.

The launchpad team had considered removing this feature two year ago because it was not popular. There were a few users who explained the need to assign questions to knowledgeable or privileged answer contacts. Simply put, the problem was not that assignment was unwanted, but that it could not be used by the people who needed the feature. The Launchpad team did not really understand how users were trying to use Launchpad until we decided to take turns answering every question asked to the launchpad project. We soon understood the need to assign questions to users. There are many questions that can only be answered by one or two people. The assignment must be visible to everyone, otherwise you would spend an hour reviewing open questions that were already assigned to someone. The cruelest part of assignment that that the assignee was never told that he has a task to complete.

This situation was especially frustrating for me because Answers is the application I started working on when I joined the Launchpad team. I knew that I could fix the issues in a few hours of work. Answers however, is not an application we are developing at the moment, I could not work on it during work hours. So I decided to fix the assignee feature on a Saturday. I could do this because the Launchpad on-call reviewer cannot easily say no to a merge request for a branch. I was also pretty certain my branch would be accepted because the reviewer is also answer contact who has experienced the assignee problems too.

The on-call reviewer rule is in place to ensure every patch is reviewed and given an opportunity to merge. This rule applies to everyone. Some Launchpad users have submitted patches for Launchpad pages and scripts and we have reviewed and merged them. Launchpad is now open source. You too can submit a branch knowing that someone must review it. Many of the Launchpad team members hack on Launchpad on our own time because we love Launchpad. Yet we still cannot fix every bug, or implement every feature. There are a lot of bugs that can be solved in a few hours work. If you want help to close a issue that you care about, we can help. Again the on-call reviewer is obligated try to advise on implementation issues. Also, Launchpad developers prefer to have pre-implementation plans to ensure that when someone decides to start a branch, it can be completed in less than two days and will be accepted by a reviewer. Someone on the #launchpad-dev channel on freenode can help.

Over several months, we have released many small improvements to the project series, milestone, and releases pages to make release planning easier in Launchpad. Well, not all the changes were small. Some were subtly disruptive. Here is an explanation if what happened that I hope will give you ideas of how we can make more improvements.

In November of 2008, Barry Warsaw and myself sprinted with Martin Albisetti to plan the Registry features for Launchpad 3.0. Martin was very insistent that we make series management easier for developers. He proposed a timeline to visualise the past and future of lines of development. You can see the first draft of this feature on the project page now. We are adding it to the series page and the series timeline page (which has always claimed to be a timeline even though it did not present one) for the next release.

I realised during the discussion of how to make the timeline that I did not like the series page, or the milestone and release pages. They looked like historical documents, they were not tools that helped me plan releases.

The immediate problem was that milestones were disconnect from releases, the former must lead to the latter. Even if your project does not use milestones for planning, the information of the milestone is implicit in the release. The release is a device for holding the release notes and the release files, all the other information is the milestone. We made the milestone the primary artefact of the series…milestones may existing long before a release, and not every milestone leads to a release. Creating a release is really an event at the conclusion of the active life of a milestone. We still permit projects to create a release directly from the series page, but you must select the milestone that is being released. If the milestone does not exist, you can create it at that moment. There is no additional work in this process; the milestone fields are the same fields that the release duplicated.

By creating a single page to present the milestone and its release, it became easy to see the planned and achieved work. The page initially shows all the bugs and blueprints targeted for the milestone and you can see the state of each one. When the release is created, the milestone is deactivated (bugs and blueprints cannot be targeted to it any more) and the release note and files are displayed.

The series page now shows the milestone and releases for the series. You can see a summary of all the work targeted to the milestone. You can see which milestones have releases. Developers can see the location of bazaar branch where they can make contributions. Distro packages are listed for distro maintainers and curious users. Adding a milestone to a series is very easy, adding many is easy too.

These pages make my job easier. They are now tools. They could be better though. Martin pressed me into adding the counts of bugs and blueprints in each status for each milestone to the series page. I can see now that they are very useful. I want to add this same summary information to the milestone page. I want to see a burndown chart on the milestone page. A burndown chart is a tool that compares the remaining work in a milestone to an ideal line to meet the milestone estimated release date. I want to know when progress is slow so that I can take action to meet my series’ schedule.

I decided to use the title of “release manager” for the driver assigned to a series. This is a UI improvement. I am a release manager, but I cannot create milestones or releases. Nor can I update these if I want to make a correction. I cannot effectively plan, nor can I create the objective of most of my plans. This sucks. I want to give the release manager the power to accomplish his objectives.

Please give this tools a try. Your feedback is appreciated, as too are your ideas for new features that make release planning easier.

In our 2.2.3 release of Launchpad — due 1st of April — we’re strengthening the relationship between milestones and releases.

Project releases will be explicitly linked to a milestone, meaning the release inherits the milestone’s series and identity information.

You’ll be able to create a new release from a milestone page or, if you don’t yet have a milestone, there’ll be an option to create a release and its parent milestone simultaneously. You can still have milestones that do not correspond to releases.

Just as now, the release will hold the release notes, changelog, date released, and any downloadable files.

What are Releases, Milestones, and Series?

Launchpad hosted projects can arrange their development into Series, which contain Milestones to which bugs can be targeted, and Releases which hold download tarballs and have release notes. Although Milestones and Releases go together, they were previously managed separately in Launchpad. Now they’re more unified.

Why are we doing this?

Many people already use releases and milestones in this way. Milestones aid release planning, and help people understand a project’s goals. Creating a release directly from a milestone implies that the milestone was reached.

Linking milestones to releases improves the data consistency between projects. With good milestone and release information, Launchpad can improve the presentation of series to explain what has happened, and what will happen. We hope that this will make it easier for people to know where and when to make contributions to your project.

This change also allows us to redesign the series, milestone, and release pages. Our goal is to better present the history and future of a project, as well as to improve the workflow for planners.

What you can do

You do not need to take any action regarding releases. We’re migrating existing releases by linking them to a milestone, or if there isn’t an appropriate milestone, creating a new one.

You can use Launchpad’s staging environment — https://staging.launchpad.net/ — right now to check what your releases
and milestones will look like under the new system.

We’d value your feedback so we can improve the data migration script. If you come across a problem, please report a bug here:

https://bugs.launchpad.net/launchpad

For other comments, send us an email to feedback@launchpad.net

How we’re making the migration

The release’s project, project series, version, code name, and summary come from the milestone it’s linked to. The release’s version will come from the milestone’s name.

When a release and a milestone share the same series and version/name, they are linked. The release’s summary will be appended to the milestone’s summary. You should review your project’s milestones. You can make changes to your project’s milestones and releases on launchpad.net to ensure they are merged correctly on staging.launchpad.net before the final migration.

When no milestone can be matched to a release, a new milestones is created from the release’s information. The milestone is not active, they will only appear on the project’s milestone page. There are a few instances where two series have a release of the same name. Milestone names are unique across a project. So the milestone’s name will contain the release’s version and series name (0.9-series-trunk). You can prevent this from happening by renaming some of your project’s releases on launchpad.net now — in most cases, the duplicate release name is on an obsolete series, or trunk. You can view all your projects series at:

https://launchpad.net/<your-project>/+series

We’re also taking the opportunity to rename a couple of things: description” becomes “summary” and the milestone’s visibility flag (in the REST API) is renamed to “active”.

We believe this change will make releases and milestones much more useful. Please do report bugs or email us if you have any comments.

Screenshots are screenshots, right? If whacking the “Print Screen” button doesn’t offer enough refinement, then surely firing up The Gimp, gnome-screenshot or knsapshot would give you what you need, wouldn’t it?

The team behind Shutter would disagree. I was interested to know what would motivate someone to develop a new screenshot app, so I asked Mario Kemper why he began work on Shutter.

Mario: Well, I am a computer science student working as QA person in my freetime. When i started to do the QA work I was looking for a neat screenshot application because we are doing a lot of documentation for the developers as well.

There were some apps like ksnapshot, gnome-screenshot etc. but they all focus on a single screenshot; no editing features, no session, no nice effects etc. So i started to develop Shutter (formerly gscrot) with these features and goals in mind.

There is another big point, though: we all spend much of our time in forums, wikis, chats etc. From time to time we need to do some screenshots and upload them so we can share them with other people so i wanted to have a built-in function to upload your screenshot with nice link-formatting so you can post the generated link directly in the forum, wiki etc.

Shutter uses Launchpad for bugs, code, translations, answers and blueprints. You can get hold of Shutter from the Shutter team’s Personal Package Archive.

Perhaps shutting out the distractions of the physical world is no longer enough.

PyRoom is a simple text editor that shuts out all the distractions you might find in a more complex editor or word processor, giving you nothing but a black screen that you can type into.

Bruno Bord has driven the project and chose Launchpad to host it. I asked him what led him to choose Launchpad.

Short answer: Because I was lazy, and I didn’t want to hack on a project management system myself. Launchpad hosts everything I wanted: code, bugs, translations.

Long answer: It’s not just the bug tracker. It’s the whole thing. Bug trackers are very interesting to track down tasks, reorder them, assign them priorities, etc. But it’s like playing all alone on a video game while you could have much more fun playing it online, with other people
involved.

I discovered Code Versioning System and then moved to Subversion, which was a massive improvement. When I had to download a source code from CVS, I used to copy-paste command lines I didn’t understand into a bash script, and run it from time to time to update my working copy. I’ve never used CVS as a committer, and I’m glad.

I was working in a small web agency where the “revision” system was just renaming the old version of a file/directory “_old”, make a copy of it, and go on with the developement. Of course, when there was another “revision” to “commit”, you had to rename it “_old2”. Hem. Pretty amazing how things can become hellish using that kind of system.

I heard about Subversion, and reading the docs, I instantly fell in love with the syntax. At last, I could version my work with commands I could grok!

I made a quick svn+trac install on our local server, and that was ready. One of the major drawbacks of Trac at the time was the impossibility to track several projects at once.

So I had to build up a trac instance for every new project. Which was fine, as soon as I could make a tiny bash script that did everything from the ground up (svn repository and trac setup).

Anyway. I started using SVN for my personal projects. A friend of mine accepted to host my trac+svn instance for pet projects on his personal web server, and everything was fine.

One day, I moved. And I went off the internet at home for 149 days. Yes. It’s a huge number of days for a geek. At work, it was ok, but it was impossible for me to commit changes about my pet projects.

After months of despair, I finally found out about Distributed Version Control. And bzr changed my life. I could work on my projects offline, commit code, branch, merge, etc, and push it back again in the main repository when internet connection came back — this is true for any DCVS, not only bzr…

But bzr isn’t very well integrated into Trac (yet). And it’s fully integrated with Launchpad.

What’s absolutely brilliant in Launchpad is the fact that any item may interact with another. You can register a branch in a project, or in your “+junk” repository, or you can link a bug to a branch or link a branch to a bug. Once the bug is fixed, you propose the branch for merging. You can build up teams, working on specific tasks on your project: bugsquad to sort out bugs, developers to commit in the main branches, translators, or a just more general team where people interested by the project can get notifcations at any time.

Hence, using LP as a project manager makes sense.

Using LP for PyRoom was an instant choice. When I retrieved the initial python script from ubuntuforums, I commited it into a bzr branch, hacked on it a bit to clean up the code, and pushed it on the fresh new project hosted on LP.

I learned a lot during the first weeks of the project: one of the best practises is to create teams. You are on your own at the beginning, but create a team anyway, and give this team read/write access to the trunk of the project. When people start to get involved, they join the team, and are granted instant access on the main branches of the project.

But the good thing with LP is that you don’t actually NEED to be part of the dev team to send code. For Gwibber, for example, I just hacked on a bug I found with my French locale the main developers couldn’t guess. I just registered a bug, created a branch, pushed my code to this branch, and proposed it for merging. It was merged without me being member of the Gwibber team or whatever. Now the bug may be closed. WIN!

My first contributions in LP were translations, IIRC (into French, what a surprise!). Again, I was not member of any team to translate small strings in my mother tongue.

You see… it’s not just the bug tracker. Any text editor can work as a bug tracker, as long as you keep your tasks up to date in a single file. It’s the whole shebang that rocks.

If you’ve had much contact with the Ubuntu community you’ll most likely have come across loco teams: local groups who promote, support and socialise around Ubuntu.

Two loco teams — South Dakota and Quebec — have combined the Launchpad Drupal modules with a customisable Drupal theme to produce the LoCo Drupal kit.

So, if you run a LoCo team and want to set up a website, the kit gives you:

• a customisable, approved, Drupal theme
• easy login using Launchpad IDs
• Drupal role assignment according to a person’s Launchpad team memberships.

The kit works with Drupal 5.x and 6.x, with support for Drupal 7.x on the way. They’re also promising fast, friendly support.

Take a look at the project’s Launchpad page for more.

Interesting post from Jay Pipes, one of developers working on the Drizzle project:

“To paraphrase the late Charlton Heston: ‘[Drizzle] is people!’

“Recently, I’ve seen the fruit that transparent, open source development bears. This fruit takes the form of engaged, motivated, and humble individuals who wish to make their mark on a project.

“Whether it’s on IRC on #drizzle, the drizzle-discuss mailing list (now with 354 active members), or via the platform which Launchpad.net provides our community, I’ve seen new developers scrambling to pick up blueprint tasks, tackle bugs (minor and major), and stamp their footprint on the code base.

“With each new face comes an entirely new perspective, a new angle, a different set of skills and experience. And I’m taking the time to chat and learn with each of them. It’s a humbling experience for me, as I learn from each person who visits the ever-growing IRC channel and mailing list. It doesn’t matter if it’s the sage advice of folks like MySQL’s Mats Kindahl, Bernt Johnsen and Roy Lyseng, or database veteran Jim Starkey. It doesn’t matter if the new face is a college student wishing to help in any small way they can. Everyone makes a difference in their own way.”

Spring is a free software real-time strategy game engine that’s available for Ubuntu via the Spring Team’s PPA.

From the Spring About page, it features:

• Large battles limited only by the power of your computer; support for up to 5000 units.
• Large, highly detailed maps in which to wage those battles, fully 3D with deformable terrain, forest fires, dynamic and reflective water, and custom skyboxes.
• Several camera modes, allowing for anything to be viewed from almost any angle.
• Fully 3D combat in land, sea, and air, with realistic weapon trajectories (physics engine).
• Many different Games, made just for Spring.
• Complex 3rd party AIs, some of which are quite good.
• An extremely powerful GUI, designed to minimize unnecessary micromanagement.
• Frequent additions and bugfixes.

There’s more on Spring’s website.

Fergus Ross Ferrier tells us about his project, Pidge.

Matthew: What is the Pidge project?

Fergus: The goal is to have an open web platform — code and data — that students can use as a robust, trusted online community for sharing relevant information across their campus: events, initiatives, courses, peer education … all via their online ‘pidgeon hole’.

The only current installation — codename MyPidge.com, and a separate project on Launchpad — is at the University of Cambridge, England.

I can’t say it’s a raving success at the moment (it’s not), but there’s strong indication that this is a worthwhile goal, and we just need to plough on and improve it to the point where it gets widespread adoption.

Matthew: What parts of Launchpad do you use for Pidge?

Fergus: Mainly code hosting and bug / blueprint tracking at the moment. As soon as someone starts using it in a locale other than the UK, we’ll look at translation, and answers I’ll think about as a primary support method for users.

Matthew: Why did you choose Launchpad?

Fergus: The bits fitted together nicely. Linux, Apple and Django all benefit from the full-stack approach, and I really don’t want to waste my time chasing the ‘best’ software project management tool. I’d simply like to trust people at Canonical to work that out for me.

Matthew: What would you like to see changed in Launchpad?

Fergus: Consumption of OpenID…?

And it’d be super-cool if the UI and workflows were so well tested for non-technical people that I could actually send ordinary users to the Bugs / Blueprints / Answers areas and get them to chip in productively, without them having to work out the whole structure of the project.

Matthew: What do you particularly like about Launchpad?

• Err, it’s free.
• It’s used for a number of high-profile open-source projects (and thus hopefully will continue to be developed and supported!)
• And I really like the open nature of the whole thing: how anybody can walk into any project listed, pick up the structure, and get involved. No politics, no asking for commit access to a repo, no hidden bug trackers.

Matthew: What’s next for Pidge?

Fergus: Well I need to learn a few things about motivating other students (and myself!) and keep ploughing on until it reaches critical mass here at the U of Cambridge.

And, as this is designed as a reusable package, I’d like to see someone at another student campus in the world taking up the gauntlet to set up a remote installation. Referrals, suggestions and introductions welcomed!

The Exaile media player has been attracting fans over the past couple of years. I asked the project’s founder, Adam Olsen, about the project and their use of Launchpad.

Matthew: It seems as though music players are a bit like mail clients: they’re a problem that you might think are easy to solve but, in practice, no one ever seems entirely happy with what’s available. How are the Exaile team tackling that problem?

Adam: Before I started Exaile, I was somewhat happy with Amarok. I liked most of it, however, I was using Gnome and Amarok was quite buggy at the time. I thought, “well, I’ll write a Gnome clone for it”, and that’s how it got started. Once I had all the features in that I wanted, it moved to the users to give ideas by requesting features.

Now it’s a cat and mouse game, to keep up with what users request. Can’t really give everyone what they want, but we do try.

Matthew: How many people contribute to Exaile?

Adam: There are three developers, and three or four people that contribute regularly with patches.

Matthew: What made you choose Launchpad and Bazaar for Exaile?

Adam: I chose Launchpad because I wasn’t in charge of hosting it. Prior to Launchpad, I was using trac on my own server, which eventually got hacked. Launchpad was a natural choice to me because Ubuntu was using it, and I chose Bazaar because Launchpad used it.

Matthew: Is your team PPA an important way to distribute stable Exaile release or just for test versions?

Adam: It’s to distribute stable versions of Exaile. Prior to PPA, I’d only distribute packages for different architectures when someone contributed them, but this is much easier

Matthew: What features do you feel are missing from Launchpad?

Adam: A wiki would be nice, or some sort of documentation section.

Matthew: Is there anything in Launchpad that is much harder than it should be?

Adam: Sometimes Launchpad is hard to navigate, but I think it’s because it does some things that no other projects do. Terminology is sometimes an issue, for instance, the word “driver” to describe the person (or team) that is in charge of decisions and bugs for a series is probably something that a new user hasn’t heard before, even though it does accuratly describe the purpose.

All in all, though, the documentation is good, and the community is very helpful, so it’s really not a big deal.

Matthew: Have you used merge proposals and code review in Launchpad?

Adam: Not extensively. We’ve had probably two or three merge proposals.

Matthew: Do you use the bug tracker’s ability to track one bug as it affects different projects?

Adam: Yes, if there is a bug Exaile and also another Python project that gets fixed, sometimes I’ll look through to see what they did to fix it.

Matthew: What’s next for Exaile?

Adam: Right now we’re doing a complete rewrite of the codebase that’ll allow features to be added more quickly and easily. It’s currently in a very usable state and we’ve released a beta. No word yet on when we’ll be done, but people seem to be pretty excited about it.

Matthew: Thanks Adam!