launchpadblog

You could argue that the free software world isn’t short of a text editor or two. With some people already pretty attached to their preferred choice, you might wonder if we really need another.

Some time ago, I read a newspaper article complaining that today’s computer desktop dangles too many distractions in front of professional writers. The author presented two solutions:

• a return to typewriters
• and Hog Bay Software’s WriteRoom.

WriteRoom is a big black box with green text. Basically, think Windows Notepad but with fancier marketing and a $24.95 price tag. Nonetheless, its simplicity has struck a chord with many; not least of all me.

That’s why I was delighted when Bruno Bord told me about PyRoom. It’s one of several WriteRoom clones that grew out of a thread on the Ubuntu forums and, as you might expect, is written in Python.

If you have Bazaar, you can get hold of PyRoom with:

bzr branch http://bazaar.launchpad.net/~brunobord/pyroom/trunk

Writing this post in PyRoom almost makes me nostalgic for my Amstrad PCW days. It’s is a work in progress so give it a try and file bug reports. Bruno’s also on the look-out for translators.

30th January 17.00 UTC in #launchpad

Launchpad isn’t just about source code, bugs, or translations. Nor packages, specifications, community support or file downloads.

Launchpad’s about people. Okay, that sounds a bit cheesy but it’s true: every new feature or improvement we make to Launchpad is designed to make it easier for you, me and anyone else to work together.

That’s why we hold monthly user meetings: talking to people who use Launchpad is absolutely the best way to find out what we can improve and what works well. You can find the Launchpad team in #launchpad and on the launchpad-users list just about any time but these meetings give you a focused opportunity to talk directly to members of the Launchpad team.

Come along to this month’s meeting on 30th January at 17.00 UTC in #launchpad on Freenode. Add your question or any other item to the agenda or simply speak up during the meeting. See you there 🙂

Over the past couple of weeks we’ve been accepting entries to our Launchpad logo competition.

Rather than store up the entries until the deadline (31st March, by the way), I thought I’d share a couple of those we’ve had so far. Of course, you don’t have to wait for me to pop up here to see what people are submitting. If you want to get an email whenever a new logo is put forward, click Subscribe on the submissions page.

I like the flow of Damián Vila’s design, which maintains a green feel similar to the present Launchpad site design. The rocket flying off from the Launchpad logo-text puts me in mind of Launchpad as just that – a launching point for work on free software projects.

Donn Ingle says he “tried to capture the fun spirit of the overall Launchpad design”. His is the first logo to move away from green and I think he does capture a sense of fun in his design. I’d love to see an animated version.

Do go see the other entries in the competition. Better still, fire up Inkscape and create your own!

This post doesn’t imply any particular favourites, by the way 🙂

Announcing the Launchpad Logo Community Design Contest.

What: Design a new logo for Launchpad
When: Now through 31 March 2008
How: See http://help.launchpad.net/logo for more details and official rules
Prize: Winner will receive an Ubuntu Messenger Bag

Another part of the Zope project – the Zope Content Management Framework (CMF) – has joined both Zope 2 and Zope 3 in using Launchpad to track bugs, making it much easier for all three to work together on common bugs.

Similarly, Soren Hansen is now using Launchpad to track bugs and host code for LibMMS, a library for connecting to Window Media streams. He told me why he wanted to host the code in Launchpad:

“I have a couple of other projects on Launchpad that I pretty much just put there to share them with co-workers and such, but out of nowhere, branches popped up with new features from people I’ve never talked to (neither before nor since).

“It’s really distributed revision system at it’s best. One of the things that could have gone wrong when people started adopting distributed version control was that changes would never flow back upstream. Adding Launchpad to the workflow makes it all come together naturally.”

The community behind Inkscape – the free software vector drawing tool – have chosen Launchpad as their new bug tracker!

Bryce Harrington, one of the project’s founders, explained why:

“The Inkscape project is gearing up for our next coming release, and based on our experience doing the past release, our current bug tracking system is really not up to the task of managing a large number of bugs.

“Launchpad has all the usual advanced bug management capabilities that we need. We’re also looking forward to making good use of the external bug tracker linking for keeping a watch on key bug reports in Cairo, Gtk, and other projects we depend on.”

Launchpad developer James Henstridge is working with the Inkscape team over the next few days to import their bug history from Sourceforge. If you’re interested in switching your project’s bug tracking to Launchpad – with complete bug history – drop us a mail to feedback@launchpad.net.

If you’re new to Launchpad, next week is a great time to find out more!

My Launchpad colleagues and I will be leading a number of IRC tutorial sessions designed to give an introduction to Launchpad and its applications. Here’s what’s on and when:

• Introduction to Launchpad: Monday 22nd 17.00 UTC and Thursday 25th 16.00 UTC.
• Launchpad Q&A: Tuesday 23rd 18.00 UTC and Thursday 25th 19.00 UTC.
• Troubleshooting with Launchpad Answers: Tuesday 23rd 20.00 UTC.
• Managing bugs in Launchpad: Thursday 25th 17.00 UTC.
• Hosting code with Launchpad: Thursday 25th 18.00 UTC.
• Launchpad Personal Package Archives: Friday 26th 15.00 UTC.
• Translating with Launchpad: Friday 26th 16.00 UTC.
• Planning features and sprints in Launchpad: Friday 26th 17.00 UTC.

These sessions are as part of Ubuntu Open Week and so will be in Freenode’s #ubuntu-classroom channel.

If you have any particular requests or suggestions for any of these suggestions, please leave a comment!

If you’re a web developer, you’ve almost certainly heard of Zope.

If you’re not familiar with Zope, here’s a quick overview. It’s a free software web application framework that comes in two flavours: Zope 2 and Zope3. The Plone and Silva content management systems use it as their base, as do several high profile websites. Our very own Launchpad makes heavy use of Zope 3.

Earlier this year the Zope 3 project (a “next generation Zope” team) adopted Launchpad for bug tracking. Now the main Zope 2 project is moving to Launchpad as well. Jim Fulton, CTO of the Zope Corporation, explained why:

“Launchpad works great and, with its many project support tools, allows us to focus on creating a great Zope platform without being distracted by developing our own project-management tools.”

The Launchpad team have helped the Zope project to move all their bug history to Launchpad, allowing them to pick up exactly where they left off. I asked Jim how smoothly the move went for Zope 3:

“Very. The Launchpad team took a custom data export format from us and imported it into Launchpad with great fidelity, keeping old issues readily accessible.”

So, other than enabling the Zope guys to do away with the burden of running their own bug tracking tool, what else does Launchpad offer them? Andreas Jung, also of Zope, explained that “managing Zope 2 and Zope 3 bugs together on LP makes sense since Zope 2 includes large parts of the Zope 3 core”.

Launchpad’s ability to track how the same bug affects different communities and projects is ideally suited to this situation.

Now, if the Zope 3 team find that one of the bugs they’re tracking also affects Zope 2, they can push that bug to Zope 2’s bug list. From that point, the bug and its comment history are shared between the two projects, while retaining separate statuses and importance levels.

I’d like to give a warm welcome to Zope 2 on behalf of the Launchpad team. If you’d like more information on using Launchpad for your project, email us or join us in #launchpad on Freenode.

Update: The Zope Content Management Framework now also uses Launchpad to track its bugs!

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!

Come and chat to some of the Launchpad team on August 15th at 16.00 UTC in #launchpad.

If you have any burning Launchpad questions, want to make a suggestion or otherwise want to chat with some of the team behind Launchpad, we’d love to meet you.

Add your question or comment to the agenda at:

https://wiki.ubuntu.com/LaunchpadUserMeeting/2007-08-15