2

Come and learn more about Launchpad

Published by Matthew Revell October 18, 2007 in General

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:

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!

0

Coming Changes in 1.1.10

Published by Matthew Revell October 8, 2007 in Coming changes

Welcome to the Coming Changes report for Launchpad 1.1.10 (which is due for release 24th October).

Here you can find information on changes that we’re planning for the next Launchpad release. These are changes that may affect the way you use Launchpad, rather than a full list of new features that will appear in 1.1.10.

Giving us your feedback

We welcome your feedback and invite you to join us on the launchpad-users mailing list.

You can also come and speak directly with the Launchpad team in the Launchpad Users Meeting on Wednesday 10th October at 16.00 UTC.

We’ll publish an updated version of this report on the 17th October.

Launchpad general

Bug Tracker

Code

Soyuz

Further information

You can find full details of what we have planned for Launchpad 1.1.10 at:

https://edge.launchpad.net/launchpad-project/+milestone/1.1.10

1

Zope 2 switches to Launchpad

Published by Matthew Revell September 26, 2007 in General

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!

8

Of Bugs and Statuses

Published by kiko September 25, 2007 in Bug Tracking, General

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:

  1. 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.
  2. 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.

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!

0

Launchpad Downtime on 2007-09-21

Published by Joey Stanford September 22, 2007 in Notifications

Earlier today we had intended to roll out some bug fixes following the Launchpad release yesterday. We do this from time to time following a release as needed to ensure the most stable environment for our users. These normally take only a few minutes to implement.

Tonight during the roll-out process we encountered an unexpected error that did not present itself during our normal QA checks. The solution to this problem requires some additional research on our part. We believe we will need to update data in Launchpad early next week in order to resolve this issue. This should not involve any further downtime.

Unfortunately this issue affects the feature in bug #50663 – “There should be a report to show Needs Info bugs that have had a response”. That feature will not work until we resolve the current situation.

We apologize for the disruption in service.

0

Launchpad 1.1.9 released!

Published by Matthew Revell September 21, 2007 in Releases

Earlier today we release Launchpad 1.1.9! So, what’s new this time round?

There’s plenty more in this release, too. Stay subscribed to this blog for more on individual features and take a look at the full 1.1.9 release notes for every last detail.

As ever, we want to hear from you and there a few ways to get in touch:

2

Launchpad privacy policy

Published by Matthew Revell September 19, 2007 in Notifications

Today, we have introduced a privacy and data retention policy that covers your relationship with Launchpad. You can find it at:

https://help.launchpad.net/PrivacyPolicy

The policy describes the ways in which we use and retain data in Launchpad, including how we:

This policy formalises what we already do and so is not a change to the way we use data in Launchpad. Please read the policy and send any questions to feedback@launchpad.net.

If you’d like to receive notifications of updates to the policy, please subscribe to the Launchpad News notification feed at http://news.launchpad.net/category/notifications/feed

0

Coming changes in Launchpad 1.1.9

Published by Matthew Revell September 14, 2007 in Coming changes

The next release of Launchpad is due on the 19th September. As always there’ll be new features, bug fixes and one or two changes to the way some parts of Launchpad work.

I’ll post full details of what’s new on the release day. For now, here are the changes that may affect the way you use Launchpad:

General Launchpad

Answers

Code

Bug tracker

You can go find more about what we have planned on the Launchpad 1.1.9 milestone page.

0

PPA and Packaging 101 class

Published by Matthew Revell September 11, 2007 in PPA

The Personal Package Archives beta has received an enthusiastic response!

If you’re interested in learning to package for Ubuntu and want to use your PPA, read on.

At 15.00 UTC on Thursday 13th September, the Launchpad and Ubuntu MOTU teams are jointly hosting PPA and Packaging 101. This IRC session in #launchpad will introduce you to:

It’s also your opportunity to ask questions about PPA and get answers from the Launchpad and MOTU teams. If you want to see a particular topic covered, add it to the class’s agenda on the Launchpad help wiki.

See you there!

0

Personal Package Archives

Published by Matthew Revell September 4, 2007 in Cool new stuff

A few years back, I switched from Red Hat to Debian for one main reason: apt. I loved the ease with which I could install and remove software that had been packaged specifically for my operating system.

Now I use Ubuntu and I still think apt rocks. I can’t even remember the last time I thought about dependencies.

Your own apt repository

Recently, we’ve been working on a new Launchpad feature: Personal Package Archives. With PPAs, you can build Ubuntu packages and make them available to other Ubuntu users in your own apt repository. Whether you’re packaging brand new stuff or creating your own versions of existing Ubuntu packages, PPA takes care of the building and hosting.

It works like this:

  1. You create an Ubuntu source package.
  2. You upload your source package to Launchpad.
  3. Launchpad builds your package for X86 and AMD64 architectures.
  4. You invite testers, friends, end-users or whoever else to add your PPA’s address to their sources.list.

Your apt repository is hosted by Launchpad and works just like any other. For example: if you upload a newer version of one of your packages, your users will automatically get the update.

Teams can also have their own PPAs. MythBuntu is one of the teams that have started using their PPA. You can view the overview of their PPA and the archive itself is at:

http://ppa.launchpad.net/mythbuntu/ubuntu/

Beta testing PPA

If you want to start building and distributing Ubuntu packages using your own PPA, the first step is to make sure you’re familiar with packaging for Ubuntu. Other than that, you simply need to join the Launchpad Beta Testers team and then follow our PPA quick-start guide.

Let us know how you get on – post a comment here and join us on the launchpad-users list.

Previous Entries
Next Entries