launchpadblog

Today, the Private Projects and Private Blueprints features on Launchpad are leaving beta. These features are available now for use by all Launchpad users. Private Blueprints was started as part of the Private Projects work, with the end goal in mind of truly private projects on Launchpad. Private Projects was described in its beta announcement like this:

When creating a new project on Launchpad, beta testers will have the option to create “Proprietary” or “Embargoed” projects. Embargoed exists for projects that intend to start private but later be revealed publicly. All other private projects should be proprietary. Milestones and series are proprietary or embargoed based on the project setting. To make them public, you will need to make the project itself public.

When you create a proprietary or embargoed project on Launchpad, all of the sharing policies for your project will be set correctly for you. This means that if you start your project as a proprietary project, your branches, bugs, and blueprints will be created proprietary by default. Answers and translations are not available for private projects.

A commercial subscription is required to use private projects, but any user who creates a proprietary or embargoed project on Launchpad will receive a 30 day trial commercial subscription. Launchpad users with existing commercial subscriptions can convert a public project to proprietary or embargoed by changing the information type in the project’s settings. You may have some work to do on your project before you can transition to a private information type — for example, disable answers if you have that app enabled for your project — but Launchpad will block the change and tell you what needs to happen before you can switch to a private information type.

Users should be aware, though, that if your project has been listed on Launchpad publicly until now, then search engines know of its existence already. If you want a proprietary project that no one can learn of its name, you should create a new project on Launchpad. Transitioning a public project to private allows you to keep your series and milestones private going forward, but users may have already been able to discover the existence of the project since it was public already.

We are happy to make truly private projects available for all users on Launchpad. If you run into any issues, please file a bug against Launchpad or ask for help in #launchpad on Freenode.

If you are part of Launchpad’s beta testers team, you can now start trialing private projects on Launchpad. The private projects feature builds on the great sharing work that Launchpad’s Purple Squad has done, allowing Launchpad users to create true private projects now. A commercial subscription is required to use private projects, but any user who creates a private project on Launchpad will receive a 30 day trial commercial subscription.

When creating a new project on Launchpad, beta testers will have the option to create “Proprietary” or “Embargoed” projects. Embargoed exists for projects that intend to start private but later be revealed publicly. All other private projects should be proprietary. Milestones and series are proprietary or embargoed based on the project setting. To make them public, you will need to make the project itself public.

Be warned, this is a large change to Launchpad and there are certainly bugs in our handling of privacy. You can check out our list of known issues, if you’d like. We, as the Launchpad Orange Squad, are committed to fixing all of those before we leave beta. So don’t worry, we’re still actively working on this feature. We did, however, want users to begin using this feature to get early feedback on the work. Don’t trial your super secret project with this feature just yet, but if you have something safe to try out private projects, now is a good time for beta testers to get going with the feature.

Enjoy private projects on Launchpad now, beta testers! And please file any bugs you find.

To go along with recent work to enable information sharing for bugs and branches, we are now enabling privacy for blueprints for beta testers. This means that blueprints now support some of the different information types that bugs and branches also support. For projects with a commercial subscription on Launchpad, this means blueprints can now be set to proprietary or embargoed. Project owners can also manage sharing for blueprints from their project’s sharing details page. For more on how sharing itself works, see Curtis’ blog post that announced that Information sharing is now in beta for everyone.

We have some minor fit-n-finish issues to complete, like nicer UI elements, and of those, we have one last known bug in progress — we know that blueprints don’t currently honor the sharing policy default when new blueprints are created. However, we thought it was worth getting this work to beta testers now to start getting feedback on this as we turn to finishing off the privacy work that is left to do.

Enjoy privacy for blueprints, beta testers! And please file bugs on any issues you find.

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!

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.

Recently, we changed the way assigning bugs works on Launchpad. It used to be that anyone could assign anyone else to a bug. This was open to abuse as you can imagine. Bug 511269 was filed about the potential problems with this, and we recently changed Launchpad so that only bug supervisors can assign a bug to someone else.

You can still assign a bug to yourself, but this does keep you from assigning someone to a bug to draw their attention to said bug. In the end, this is a good thing, though, as people should only be assigned bugs who are going to be responsible for working on them.

Now there is one issue with this change. Projects that had not established a bug supervisor for the project will find their developers can no longer assign bugs to each other. The easy fix for this is to create a bug supervisor team for your project and have the people working on your bugs assigned to this team. We do realize this might be a bit heavy weight for some projects, so we’ve opened bug 603281 about this issue.  A fix for this — only requiring bug supervisor permissions if bug supervisor is defined — should be appearing on Launchpad soon.

Many different types of information are stored in bug reports in Launchpad.

Some are actual defects, some are feature requests, some are general issues, and so on.  It is not uncommon on Launchpad to have a bug that deals with an issue that a developer cannot resolve.  In Launchpad, we offer a couple of bug statuses that allow a developer to close a bug report without actually doing what is requested in the report: these are Won’t Fix and Invalid.

Often, though, there may still be a discussion. Won’t Fix and Invalid are useful for the developer, and the project, to know that they don’t need to schedule time for a fix. However, they can sometimes — rightly or wrongly — be seen as an attempt to close down to discussion.

We’ve just added a new bug status to Launchpad: Opinion. Now, this is a fairly momentous occasion; we hardly ever make changes to bug statuses because they, naturally, have a great impact on how you and others use Launchpad to track bugs. However, we feel it’s important to find a way to balance a project’s need for useful work planning with the need for intelligent and open discussion.

Opinion says: there’s a difference of opinion around this bug and people are free to continue the discussion, but the project or package maintainers need to move to other work and are considering the issue closed.

Like I said, adding a new bug status to Launchpad is a big deal. So, we’re treating Opinion as an experiment. We’ll watch how it is used over the next three months and then we’ll decide if the status is proving useful and effective at closing bugs while leaving the discussion open.

I’d love to hear your views on this new status: leave a comment here, join us on the launchpad-users mailing list or mail me directly.

There are a couple of new features related to patch handling in Launchpad bugs this month.

Building on the work we did in December to better distinguish patches in bug pages, we now use an icon to show if a bug has a patch attached in bug listings.  Any search on Launchpad will now indicate if a bug has a patch attached.  Look for the band aid icons, and you’ll know that a bug has a patch attached.

Also, bug mail notifications have been updated to distinguish patches from any other attachment.  Now when a patch is added or removed from a bug the email notification will read “Patch added” or “Patch removed” to make spotting patches easier in email.

These are small improvements to our handling of patches to help patches become more easily spotted on Launchpad.  Combined with our work on sorting bugs by a heat number, the Launchpad bugs app is doing more to let users know about the state and quality of a bug report.

Some Launchpad users may have noticed that we are not syncing bug watches with external trackers as we should. We have had to turn off syncing with external trackers while we work on a problem we have had with hammering bug trackers with large numbers of bug watches in Launchpad.

The Launchpad Bugs team has been doing a lot of work recently to improve our handling of bug syncing between Launchpad and external trackers. We’ve fixed several bugs. Unfortunately, we cannot re-enable syncing with external trackers until we are certain we will not hammer an external tracker.

We expect bug syncing to be down through the weekend and fixed early next week. Interested developers can follow progress at the bug linked above.

Launchpad’s 3.1.12 release has been a big release for the Launchpad Bugs team, despite it only being a two week development cycle compared to the normal four week cycle for Launchpad releases.  This meant there was really only a week of development time for the bugs team.  We’ve been anxious to really put some development effort to the plans we’ve been articulating at sprints and UDS over the last few weeks prior to the start of the 3.1.12 cycle, so we discussed in our team being very careful with our time during this short cycle so that we could end the year with a hint of the work to come over the next 2-3 months.

Better Patch Tracking

One of the things we’ll be working on over the next months is better patch tracking and reporting in Launchpad.  The first fruits of this have landed with changes to distinguish patches in comments and to list patches separately on the bug page.

Now when you attach a patch to a Launchpad bug, the patch has a new icon to distinguish it from any other attachment.

Patches are also now listed separately in the sidebar from other attachments on the bug page.

This work is part of the larger story of better patch tracking in Launchpad which will be one of three stories within the larger story of connecting Ubuntu, upstreams, and users that the bugs team will focus on in the next few months of development work.

Stopping Filebug Timeouts

Another nice change is the filebug work that Graham already posted about when he put out his call for early testing.  This changes lands with 3.1.12 and filing a bug should rarely time out now.

Showing Affected Users

Also, Martin previously blogged about our now showing the number of affected users on a bug page.  This is part of the story we’re calling Bug Q&A and also relates to our efforts to deliver a quality bug heat metric on Launchpad bugs.

More to Come From the Bugs Team

Each of these when taken on their own is not a large new feature, but it’s a nice bit of work for just a week’s worth of development.  Hopefully, this will also give Launchpad users a sense of what is to come in the next few months of development in the Launchpad Bugs application.  If you’re interested in following development on the Launchpad Bugs team, or maybe you’ve thought of contributing to the code, then you can check out the bugs team development plans on the Launchpad dev wiki.