launchpadblog

As of recently, you have more control of what email Launchpad sends you about bugs.

Instead of bug subscriptions being all or nothing, you can now tell Launchpad exactly what bug-related events you want to hear about. And if you find you’re getting too much, or too little, detail you can change your subscription at any time.

What’s more, it’s now easier to filter the bug mail that Launchpad sends you.

Subscribing to an individual bug

Let’s take a look at a bug report about Gwibber. Over on the right-hand side is the Subscribe link as usual. Clicking on it, though, gives us three new options for when Launchpad should email you about this bug:

• a change is made to this bug or a new comment is added
• any change is made to this bug, other than a new comment being added
• this bug is fixed or re-opened.

You get to choose how much detail you want about the life of this bug, from receiving an email about everything through to Launchpad notifying you only when the bug is fixed or subsequently re-opened.

Editing a subscription to an individual bug

You can change your mind about your bug subscription. Simply click the Edit subscription link that appears once you’ve subscribed.

You get the same options, along with an additional option of unsubscribing entirely.

Subscribing to a project

You’ve been able to subscribe to all the bugs in a particular project or distribution (and milestone, series, packages within those) for a few years now. However, for anything but the quietest of projects this could bring a new intensity to the phrase “drinking from the fire hose”.

Now you can have sane subscriptions to these broader structures within Launchpad. Let’s subscribe to bugs in OpenStack to see how it works.

Clicking Subscribe to bug mail on OpenStack’s bug overview page gives allows you to:

• subscribe yourself or one of your teams
• name the subscription — this gets added to the emails that result
• choose whether you want to hear when a bug is opened or closed, or if you want to go into more detail.

So, now you have a subscription called OpenStack overview that’ll generate an email whenever a bug report is opened or closed in OpenStack.

Refining a project subscription

Let’s say you’re particularly interested in OpenStack documentation. No problem, you can keep your OpenStack overview subscription for everything else and add a more detailed subscription just for documentation bugs.

If that’s not enough, you can also filter by importance and status.

Muting bugs

If a particular bug becomes too noisy, you can mute it. No matter how you’re subscribed to that bug — even if you have several subscriptions that generate email about that particular report — once you’ve muted it, you won’t hear about that bug again.

Of course, you can unmute it any time you like.

Unsubscribe in anger

At the bottom of every bug mail that Launchpad sends you’ll now find a link to edit your subscriptions to that bug. So, no matter how how you’re subscribed to the bug you’ll find all those subscription listed on that page and have the option to edit each of them.

You can also get to that page by clicking Edit bug mail on the bug page itself.

And there’s more

To help with filtering, Launchpad now adds a new header to bug emails:

X-Launchpad-Subscription

It quotes the name you gave the subscription when you created it. For Gmail users, all bug emails also feature the subscription name in the footer of the email body.

And don’t forget that you can already opt-out of email about your own actions on bugs and Launchpad won’t send email about quickly corrected mistakes.

I know I’m going to find bug mail easier to deal with now. Congratulations to the Yellow Squad on delivering this feature!

Did you know we’re running a beta of Launchpad’s new bug subscriptions system?

If so, you may have heard that we were planning to take the new subscriptions system out of beta today.

There are, though, a couple of bugs that we want to fix before taking the new bug subscriptions system live. And one of those bugs requires an update to our database, which means a short amount of read-only time for Launchpad.

So, we’re now planning to make the new bugs subscription system live on June the 8th, which is our next scheduled database roll-out.

If you want to start using the new system straight away, join our beta team!

Photo by Jordiet. Licence: CC BY SA 2.0.

If you’ve ever wondered why a particular bug report about the Launchpad project is marked as Low, High or Critical, you should read our bug triage guidelines.

Okay, so, if you’re not directly involved with triaging Launchpad bugs then that may not be the world’s most compelling invitation.

So, here’s the short version: we use only the Critical, High and Low importances. We give each a particular meaning:

• Critical: Bugs that should be fixed before other bugs. Ideally, we’d have nothing here.
• High: Bugs we think we can fix in the next six months.
• Low: Everything else.

That last one can make it appear that we don’t care about your bug but that’s not the case. The reason we use Low is to avoid setting any unrealistic expectations about when someone in the Canonical Launchpad team will get to that bug. That’s not to say we’d complain if someone else fixed that bug. Also, we’re open to persuasion: tell us why we should increase the priority of a bug you care about.

There’s more in our bug triage guidelines, including what we consider to be a Critical bug.

Photo by Mr. T in DC. Licence: CC BY ND 2.0

Ever wished you got less bug mail? Or perhaps that you could better control the bug mail that Launchpad sends you?

Recently, Gary and the yellow squad, plus before them the previous Launchpad bugs team, have been working to give you just that: better control of the email that Launchpad sends you about bugs.

The yellow squad are spending the next couple of weeks adding some additional polish to the new bug subscriptions and notifications system. If you’re part of the Launchpad beta testers team, though, you’ve got access to it right now.

So, if you are a Launchpad beta tester, here’s what to look out for when dealing with bug subscriptions:

• You can now choose which events will trigger an email and filter them by types of status, importance, etc., when you subscribe to a series, project or distribution.
• As a result, you can have more than one bug subscription to the same series, project or distribution, each subscription with its own name.
• You can mute individual bugs.
• Bug mail that results from a named subscription has a “X-Launchpad-Subscription” header, and a line in the body of the email, quoting the name you gave the subscription.
• You can see, and edit, all the different ways in which you might receive email about a particular bug by clicking “Edit bug mail” on a bug page.

I’ll announce the feature properly, with a nice fancy screencast and all that jazz, when we release it in full.

If you’ve got any questions, come join us on the launchpad-users list. If you come across any bugs, please report them with the “story-better-bug-notification” and “beta-team” tags.

Anyone can join the Launchpad beta testers team and, unlike Hotel California, you can leave at any time.

Photo by Nils Geylen. Licence: CC BY SA 2.0

Brian Murray has written a GreaseMonkey script to show how many duplicates a bug has.

He writes:

I was looking at a bug with a large number of duplicates the other day and found my self wondering exactly how many duplicates it had. This information actually appears in the page source for the bug report however its a bit hard to read there!

I’ve hightlighted the duplicate count in the screenshot to really point out where it is.

I’ve also updated the firefox-lp-improvements PPA which contains a Firefox extension collecting all of the Launchpad Greasemonkey scripts with the new script.

Back in February, Martin wrote that we’d re-enabled Launchpad’s bug expiry feature. This meant that, if a project had enabled bug expiry, Incomplete bugs that appeared to be abandoned would be automatically marked Expired after 60 days.

This worked for a while and then broke. Normally, our monitoring scripts would have have alerted us to the problem but, by an unfortunate coincidence, a separate bug meant that the alert for bug expiry was also broken.

Both bugs are now fixed and bug expiry is working again. Shortly after the fix went live, Launchpad expired roughly 2,000 bugs that would have expired anyway over the past few months.

From now on, Launchpad will expire bugs in the usual way. A bug is a candidate for expiry if:

• it has the Incomplete status
• the last update was more than 60 days ago
• it is not marked as a duplicate of another bug
• it has not been assigned to anyone
• it is not targeted to a milestone.

If you run a project and you’d previously had bug expiry set to on, but have decided you no longer want it, follow the Configure bug tracker link on your project’s bug overview page and then de-select the Expire “Incomplete” bug reports when they become inactive check-box.

Photo by Windell Oskay. Licence: CC-BY

Rob asked on the launchpad-dev list whether people would mind seeing slightly inaccurate bug counts on some pages in Launchpad, if it meant the page would load faster.

So, if a project had 503 bugs its bug overview page might report that it has 500 bugs. However, for small numbers Launchpad would continue to report an accurate number, as the difference between three bugs and, say, no bugs is immense.

What do you think? Is a slightly inaccurate bug count a price worth paying for a faster page load? The survey closes 17.00 UTC Monday.

If you can’t see the survey embedded in this post, follow this link.

Launchpad’s bug mail can be a bit chatty sometimes as I’m sure you’ve noticed.  This cycle the Yellow Squad is working to give you more control about the bug mail Launchpad sends to you.

One problem that we’ve known about for a really long time was reported as bug 548 and has recently been closed thanks to the effort of  Данило Шеган and Gary Poster.  Their fix allows you to globally specify whether you want to receive email about actions you did.

Most people probably do not need to be reminded of something they did a few minutes ago and will want to turn off those emails.  But, since this is new functionality we’ve preserved the old behavior unless a user changes the setting.  If you do nothing you’ll continue to get email about actions you instigate on bugs.

Opting out of those messages is easy.  Simply go to https://launchpad.net/people/+me/+edit and uncheck the box as shown below by the big red arrow.

As mentioned, this is just the first of many features and refinements that we’re working on to help you customize the stream of bug mail coming from Launchpad to suit your needs.

We have a small quandry on the Launchpad development team at the moment. As bug 268508 discusses, when one searches for a bug on Launchpad we do a substring search on the names of bug targets.

For instance, searching in Ubuntu for ‘gcc’ will return all bugs on the packages ‘gcc’, ‘gcc-4.4’, ‘gcc-4.3’, ‘gcc-3.3’ and so forth. Likewise search for bugs in a project group will do a similar substring search on each of the individual projects in the project group.

It turns out that doing this search is itself expensive. I asked on the Ubuntu devel list about turning it off. We would close bug 268508 and also significantly improve search performance.

However this is a possibly contentious change – there was one mail strongly in favour of the current behaviour – so I’d like to get this change proposed to a wider community.

If you’ve got a strong opinion – that the current behaviour is good, or like bug  268508 describes, that its a poor behaviour and we would be better off without it, then I’d love to hear from you. Just leave a comment on this post, drop me an email – robert at canonical.com – or post to the launchpad-users mailing list.

Thanks,
Rob (LP technical architect)

We are starting to rollout features more rapidly on Launchpad as we move to a continuous deployment model.  There are some fixes being deployed today that I want to give Launchpad users a heads up about.  These are fixes meant to make the life of a bug supervisor easier.

Bug 114766, Only bug supervisor should be able to nominate a bug for release

Nominating to release has in the past been used as a mechanism to request that the bug be fixed, which is not what the feature is for, and we’ve now made it where only the bug supervisor for a project can nominate a bug for a series.

Bug 347218, Allow bug supervisors to make tags official

Until now, only project maintainers could make a tag an official bug tag.  Now bug supervisors have this ability, too.

Bug 664096, Fix Released should be locked against reopening

Bug supervisors waste time when they have to fix the status of a bug that had been marked fixed but later changed by someone else who mistakenly thinks they have the same bug or has the same problem in an older release.  The option to change a fixed bug to another status is now limited to bug supervisors.

There’s even more goodness to come as we get close to daily updates of Launchpad.  Stay tuned!