Canonical Voices

Posts tagged with 'bug tracking'

Curtis Hovey

We are reimagining the nature of privacy in Launchpad. The goal of the disclosure feature is to introduce true private projects, and we are reconciling the contradictory implementations of privacy in bugs and branches.

Launchpad will use policies instead of roles to govern who has access to a kind of privacy

We are implementing three kinds of policies, proprietary, embargoed security, and user data. The maintainer is the default member of these policies. The maintainer can share a kind or private data by adding a user or team to a policy.

For proprietary projects, the maintainer can add their organisational teams to the proprietary policy to share all the project information with the team members.

For Ubuntu, the maintainer will set the apport bot to be the only user in the user data policy; user data is only shared with a bot that removes personal data so that the bug can be made public. The Ubuntu security team will be the only users in the security policy.

Most maintainers will want to add project drivers to the policies if they use drivers. Bug supervisors can be added as well, though the team must be exclusive (moderated or restricted).

You can still subscribe a user or team to a private bug or branch and Launchpad will also permit the user to access it without sharing everything with the user. The existing behaviour will continue to work but it will be an exception to the normal rules.

Polices replace the bug-subscription-on-privacy-change rules. If you have every had to change the bug supervisor for a project with many private bugs, you can rejoice. You will not need to manually update the subscriptions to the private bugs to do what Launchpad implied would happen. Subscriptions are just about notification. You will not be notified of proprietary changes is proprietary information is not shared with you. Sharing kinds or information via policy means that many existing private bugs without subscribers will finally be visible to project members who can fix the issue.

Read more
Curtis Hovey

We are reimagining the nature of privacy in Launchpad. The goal of the disclosure feature is to introduce true private projects, and we are reconciling the contradictory implementations of privacy in bugs and branches.

We are adding a new kind of privacy called “Proprietary” which will work differently than the current forms of privacy.

The information in proprietary data is not shared between projects. The conversations, client, customer, partner, company, and organisation data are held in confidence. proprietary information is unlikely to every be made public.

Many projects currently have private bugs and branches because they contain proprietary information. We expect to change these bugs from generic private to proprietary. We know that private bugs and branches that belong to projects that have only a proprietary license are intended to be proprietary. We will not change bugs that are public, described as security, or are shared with another project.

This point is a subtle change from what I have spoken and written previously. We are not changing the current forms of privacy. We do not assume that all private things are proprietary. We are adding a new kind of privacy that cannot be shared with other projects to ensure the information is not disclosed.

Launchpad currently permits projects to have default private bugs and branches. These features exist for proprietary projects. We will change the APIs to clarify this. eg:

    project.private_bugs = True  => project.default_proprietary_bugs = True
    project.setBranchVisibilityTeamPolicy(FORBIDDEN) => project.default_proprietary_branches = True

Projects with commercial subscriptions will get the “proprietary” classification. Project contributors will be able to classify their bugs and branches as proprietary. The maintainers will be able to enable default proprietary bugs and branches.

Next part: Launchpad will use policies instead of roles to govern who has access to a kind of privacy.

Read more
Curtis Hovey

We are reimagining the nature of privacy in Launchpad. The goal of the disclosure feature is to introduce true private projects, and we are reconciling the contradictory implementations of privacy in bugs and branches.

We must change the UI to accommodate the a kind of privacy, and we must change some existing terms because to avoid confusion.

We currently have two checkboxes, Private and Security that create 4 combined states:

  • Public
  • Public Security
  • Private Security
  • Private something else

Most private bugs in Launchpad are private because they contain user data. You might think at first that something that is just private is proprietary. This is not the so. Ubuntu took advantage of defects in Launchpad’s conflation of subscription and access to address a kind of privacy we did not plan for. Most private bugs in Launchpad are owned by Ubuntu. They were created by the apport bug reporting process and may contain personal user data. These bugs cannot be made public until they are redacted or purged of user data. We reviewed a sample of private bugs that belong to public projects and discovered more than 90% were made private because they contained user data. Since project contributors cannot hide or edit bug comments, they chose to make the bug private to protect the user. Well done. Launchpad needs to clarify when something contains user data so that everyone knows that it cannot
be made public without removing the personal information.

Public and private security bugs represent two states in a workflow. The goal of every security bug is to be resolved, then made public so that users are informed. People who work on these issues do not use ”public” and “private”, they use “unembargoed” and “embargoed”.

Also, when I view something that is private, Launchpad needs to tell me why. The red privacy banner shown on Launchpad pages must tell me why something is private. Is it because the page contains user data, proprietary information, or an embargoed security issue? This informs me if the thing could become public.

When I want to change somethings visibility, I expect Launchpad to show me a choice that clearly states my options. Launchpad’s pickers currently shows me a term without an explanation, yet Launchpad’s code does contain the term’s definition. Instead of making me search help.launchpad.net (in vain), the picker must inform me. Given the risks of disclosing personal user data or proprietary information, I think an informative picker is essential. I expect to see something like this when I open the visibility picker for a bug:

Branches require a similar, if not identical way of describing their kind of information. I am not certain branches contain user data, but if one did, it would be clear that the branch should not be visible to everyone and should not be merged until the user data is removed.

Next post: We are adding a new kind of privacy called “Proprietary” which will work differently than the current forms of privacy.

Read more
Dan Harrop-Griffiths

Customisable bug listings in beta!

A custom bugThe information displayed with bug listings is often not what you want to see – you might not be interested in bug heat and want to see bug age, but it’s not there.  Looking at this problem, we’ve come up with a new beta feature: custom bug listings.  A lot of you have said that you’d like to be able to filter bugs in a way that works best for you. Hopefully this new functionality should help with this goal:

  • You’ll be able to sort bugs by criteria such as name, importance and status.
  • You can put them into ascending or descending order without having to reload the page.
  • You’ll be able to save your preferred layout.

We’ve also redesigned how bug listings are displayed – fitting more information into each bug listing, and adding sort options such as bug age, assignee, reporter, and tags.

We’ve done some successful rounds of user testing and would love to hear your options on this great new feature. We’ve just released it into beta. To see it, you need to be part of Launchpad Beta Testers. To try it out, take a look at any bugs listing, like this one for Openstack.

Let us know how you get on with it: either report a bug (using the bug tag bug-columns) or join us on launchpad-users.

2011/11/28 update: we have temporarily suspended the beta, but we’ll have it back in the next day or so

Photo by Stephen Fulljames. Licence: CC-BY-SA.

 

Read more
Curtis Hovey

Launchpad is ending support for multi-tenancy for branches and bugs to ensure that projects can manage the disclosure of private information. This is a fundamental change to how launchpad permits communities to share projects. Very few users will be affected by this change, but several communities will need to change how they work with private bugs and branches.

Launchpad currently permits users to create private bugs or branches that cannot be seen by the project maintainers, or the project’s other communities. This feature permits communities and companies to develop features in secret until they are ready to share their work with the other communities. This exclusivity feature is difficult to use, difficult to maintain, and makes Launchpad slow. This feature also contradicts the project maintainer’s need to be informed and to manage the disclosure of confidential information. When multiple parties can control privacy on a project, important information is lost.

While discussing the proposed changes with Launchpad stakeholders, I was surprised that most believed that the project maintainers could see the private bugs they were reporting — they wanted to collaborate, but the subscription-as-access mechanism is faulty. There are thousands of private bugs reported in Launchpad that cannot be fixed because the person who can fix the issue is not subscribed.

A contributing reason to drop support for private branches on project you do not maintain is that the feature is fundamentally broken. Privacy is inherited from the base branch. If you cannot access the base branch your branch is stacked on, you are locked out. Project owners can, and accidentally do, lock out contributors. You cannot subscribe someone to review the security concerns in your branch if that user does not have access to the base branch. Project contributors must subscribe each other to their respective branches to collaborate on a fix or feature.

This change is a part of a super-feature called Disclosure. To ensure that confidential data is not accidentally disclosed, project maintainers will be able to view and change who has access to confidential project information. Maintainers can add users to security or proprietary policies to grant access to all the information in the respective policy. You will not need to subscribe users to individual bugs or branches, unless you want to grant an exception to a user to access one confidential piece of information.

Read more
Curtis Hovey

Launchpad will soon permit you to say your project is not affected by a bug shared with another project — you can delete the spurious bug task. This action can be done from the bug’s web page, and using Launchpad API.

You can remove a project from a bug if you are the project maintainer, bug supervisor, or are the person who added the project to the bug. This action can only be performed when the bug affects more than one project — you cannot delete an entire bug. This feature permits you to undo mistakes.

Launchpad beta testers will see the remove action next to the affected project name in the affects table.

Delete spurious bugs

The delete() method was added to the bug_task entry in the Launchpad API. There is a example API script, delete_bugtasks.py, that can remove a project from many bugs. There is also a split action to create a separate bug just for the specified project to track separate conversations in bug comments.

Usage: delete_bugtasks.py [options] bug_id:project_name [bug_id:project_name]

Options:
  -h, --help            show this help message and exit
  -v, --verbose
  -q, --quiet
  -f, --force           Delete or split bug tasks that belong to a public bug
  -d, --delete          Delete a spurious project bug task from a bug
  -s, --split           Split a project bug task from an existing bug so that
                        the issue can be tracked separately
  -w WEBSITE, --website=WEBSITE
                        The URI of Launchpad web site.
                        Default: https://api.launchpad.net;
                        Alternates: https://api.staging.launchpad.net,

https://api.qastating.launchpad.net

Previously, you could not remove spurious bug reports about your project. Many were cause by poor bug target management; you could not move a bug between projects and distributions. You can now move bugs between projects and distributions, but thousands of bugs still wrongly claim to affect a project or distribution. This causes clutter on bug pages and searches, and it causes Launchpad performance problems.

This change is a part of a super-feature called Disclosure. To ensure that confidential data is not accidentally disclosed, Launchpad will only permit private bugs to affect a single project. Soon, you may need to remove a project from a bug before marking the bug private.

Read more
Martin Pool

We’ve recently deployed two features that make it easier to find bugs that you’re previously said affect you:

1: On your personal bugs page, there’s now an Affecting bugs that shows all these bugs.

2: On a project, distribution or source package bug listing page, there’s now a “Bugs affecting me” filter on the right (for example, bugs affecting you in the Launchpad product).

Counts of the number of affected users already help developers know which bugs are most urgent to fix, both directly and by feeding into Launchpad’s bug heat heuristic. With these changes, the “affects me” feature will also make it easier for you to keep an eye on these bugs, without having to subscribe to all mail from them.

screenshot of

Read more
Matthew Revell

Automatic confirmation

ConfirmYou report a bug. Someone clicks “This affects me too” or marks the bug as a duplicate of another bug report.

Both of those are confirmation of your bug, right?

That’s what we think and members of the Ubuntu community agree.

So, from now on, that’s what’ll happen with New Ubuntu and Launchpad project bugs.

To recap: Launchpad will mark Confirmed any Ubuntu or Launchpad bug that has the New status and affects more than one person or is marked as a dupe.

Oh, but it doesn’t count if you mark your own bug as a dupe of another bug you reported.

We’re considering rolling this out for all projects in Launchpad. If your project uses Launchpad as its bug tracker, let us know what you think.

Photo by Seth Anderson. Licence: CC-BY-SA

Read more
Matthew Revell

Small thing this: when you change a tag on a bug, the email notification from Launchpad describes it as removing the original tag and adding a new tag.

That makes sense but something slightly irritating was that Launchpad would order the email like this:

Tags added: qa-needstesting
Tags removed: qa-untestable

The reverse order always seemed more sensible to me: i.e. first show the tags that were removed and then show the tags that were added.

Well, I wasn’t the only one to think that way and I’m glad to say that my team-mate Huw has fixed it so that bug mails now show the tags removed before the tags added.

Read more
Matthew Revell

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.

Subscribe to a bug

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.

Edit a bug subscription

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.

Subscribe to OpenStack

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.

Subscribe to a tag

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.

Mute bug mail

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!

Read more
Matthew Revell

DelayedDid 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.

Read more
Matthew Revell

How we triage Launchpad bugs

M and Ms sorted by colour

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

Read more
Matthew Revell

A yellow bug, geddit?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

Read more
Matthew Revell

See the number of duplicates

Duplicate bug countBrian 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.

Read more
Matthew Revell

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.
The option to enable bug expiry for a project

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.

Read more
Matthew Revell

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.

Create your free online surveys with SurveyMonkey, the world’s leading questionnaire tool.

Read more
Brad Crittenden

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.

opt out of bug mail

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.

Read more
Robert Collins

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)

Read more
Deryck Hodge

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!

Read more
Deryck Hodge

I recently sent out an email to Launchpad users who had selected the “expire incomplete bug reports” option for their project, explaining that we would be enabling this feature again in Launchpad. Well, actually, I sent out a lot of emails. This happened partly due to poor design of the script I wrote to send the emails and partly due to my own error. I am sorry for the inconvenience this may have caused anyone. We are taking steps to ensure this sort of poorly executed mass emailing doesn’t happen again on Launchpad.

For those who haven’t heard, the rest of this blog post is meant to fill you in on the coming changes.

What is about to change?

Launchpad has always advertised that we auto-expire incomplete bugs matching certain conditions, but we haven’t done this for awhile now.  We are ready to turn this feature back on.  This means that bugs that are considered inactive will have their status automatically changed from Incomplete to Expired.  For more detail on how Launchpad determines if a bug is inactive, visit our Bug Expiry help page.

This change will take effect in about two weeks, sometime during the week of 18 October 2010.

What this means to you?

If you maintain a project in Launchpad and you want this feature, you need to ensure that the Expire “Incomplete” bug reports when they become inactive option is selected for your project on it’s Configure bug tracker page.  We have disabled it for all projects since it has been selected by default but inactive up until now. Sometime before the week of 18 October, you’ll need to re-enable this option if you want to take advantage of automatic bug expiry.

If you maintain a project in Launchpad and you do not want this feature, you do not have to do anything.

For maintainers of Ubuntu packages in Launchpad, we have left this option enabled. Getting this feature re-enabled was driven largely by requests from Ubuntu developers, so we have not changed the config options for Ubuntu packages in Launchpad.

If you have any other questions about this, feel free to leave a comment here or contact me on Launchpad.

Read more