Release planning
Published by Curtis Hovey June 29, 2009 in Projects
Over several months, we have released many small improvements to the project series, milestone, and releases pages to make release planning easier in Launchpad. Well, not all the changes were small. Some were subtly disruptive. Here is an explanation if what happened that I hope will give you ideas of how we can make more improvements.
In November of 2008, Barry Warsaw and myself sprinted with Martin Albisetti to plan the Registry features for Launchpad 3.0. Martin was very insistent that we make series management easier for developers. He proposed a timeline to visualise the past and future of lines of development. You can see the first draft of this feature on the project page now. We are adding it to the series page and the series timeline page (which has always claimed to be a timeline even though it did not present one) for the next release.
I realised during the discussion of how to make the timeline that I did not like the series page, or the milestone and release pages. They looked like historical documents, they were not tools that helped me plan releases.
The immediate problem was that milestones were disconnect from releases, the former must lead to the latter. Even if your project does not use milestones for planning, the information of the milestone is implicit in the release. The release is a device for holding the release notes and the release files, all the other information is the milestone. We made the milestone the primary artefact of the series…milestones may existing long before a release, and not every milestone leads to a release. Creating a release is really an event at the conclusion of the active life of a milestone. We still permit projects to create a release directly from the series page, but you must select the milestone that is being released. If the milestone does not exist, you can create it at that moment. There is no additional work in this process; the milestone fields are the same fields that the release duplicated.
By creating a single page to present the milestone and its release, it became easy to see the planned and achieved work. The page initially shows all the bugs and blueprints targeted for the milestone and you can see the state of each one. When the release is created, the milestone is deactivated (bugs and blueprints cannot be targeted to it any more) and the release note and files are displayed.
The series page now shows the milestone and releases for the series. You can see a summary of all the work targeted to the milestone. You can see which milestones have releases. Developers can see the location of bazaar branch where they can make contributions. Distro packages are listed for distro maintainers and curious users. Adding a milestone to a series is very easy, adding many is easy too.
These pages make my job easier. They are now tools. They could be better though. Martin pressed me into adding the counts of bugs and blueprints in each status for each milestone to the series page. I can see now that they are very useful. I want to add this same summary information to the milestone page. I want to see a burndown chart on the milestone page. A burndown chart is a tool that compares the remaining work in a milestone to an ideal line to meet the milestone estimated release date. I want to know when progress is slow so that I can take action to meet my series’ schedule.
I decided to use the title of “release manager” for the driver assigned to a series. This is a UI improvement. I am a release manager, but I cannot create milestones or releases. Nor can I update these if I want to make a correction. I cannot effectively plan, nor can I create the objective of most of my plans. This sucks. I want to give the release manager the power to accomplish his objectives.
Please give this tools a try. Your feedback is appreciated, as too are your ideas for new features that make release planning easier.
Extra options when filing bugs
Published by Gavin Panella June 26, 2009 in Bug Tracking, Cool new stuff
You may have noticed that we introduced some useful new options when filing bugs. These are especially useful to anyone who files lots of bugs.
Something for everyone.
Everyone can now set tags when filing a bug. Previously, only people going via the advanced bug filing page would have the option.
One caveat: the tag field is not yet wired up with the magical tag auto-completer that you can use on the bug page itself, but that’s coming.
Something for bug supervisors.
If you’re filing a bug against a project for which you’re a bug supervisor, some additional fields appear in the new Extra options area (which is collapsed by default, but can be expanded by clicking on it). There are options to let you to set the initial status, the importance and the milestone of the bug, and also assign it directly to someone to work on.
If you have any problems with these new features, please file bugs against Launchpad Bugs, or talk to the help contact in #launchpad on freenode.
Series dashboards
Published by Matthew Revell June 24, 2009 in Cool new stuff
Up until now, series overview pages have offered a historical overview of a series. Today, we’ve released our new series overview pages that work much more like a dashboard for people driving a series.
Before we look at the new dashboards, let’s clear up some terminology: to clarify the difference between the roles, we’ve changed the name “series driver” to the more familiar term “release manager”. Most projects use series as lines of development that result in one or more releases and so it makes sense to reflect that in the role’s name.
Project drivers remain as they are.
So, back to the new series dashboards: take a look at the page for Drizzle’s trunk series and you’ll see that the page now has a whole load of information that makes it easier to see the current state of that series. Perhaps of most interest is the Milestones and releases section.
At a glance, you can see how much work is planned for the series’ upcoming milestones and the progress being made with those blueprints and bugs.
Further down on the page you get links to the series’ mainline Bazaar branch and details of packages associated with the series.
If you’re a series release manager, let us know what other information you’d find useful on the series dashboards.
Searching bugs with tags now with wings!
Published by Gavin Panella in Bug Tracking
Even if you’ve been living on Earth, you could be forgiven for not knowing about the richer tag syntax in the advanced bug search (e.g. in Bugs in Ubuntu: Advanced search), frankly because it’s very new and it’s not mentioned anywhere in the UI (yet). There are two additions to the syntax that a handful of hardcore Launchpadders have been yearning after for some time.
First up, you can search for bugs with any tag, doesn’t matter which, and for bugs with no tags. To search for the presence of one or more tags, use “*” (asterisk) in the query, and to search for the complete absence of tags, use “-*” (minus asterisk).
Secondly, you can search for the absence of a specific tag. Simply prefix the tag with a minus, e.g. “-toaster”.
You can combine these new forms as well. For example, to search for bugs with no tags at all or with no crumpet tag, you could search for “-* -crumpet“, making sure the Any radio button is selected. Everybody needs crumpets!
Have fun!
If you run into any problems, please report the bug in Malone.
Project timelines
Published by Matthew Revell in Cool new stuff
New on project overview pages: project timelines.
Here’s the timeline from the Drizzle project. Straight away you can see how many series — i.e. major lines of development — are running concurrently, along with releases and milestones. Click on any of them to get more info.
Launchpad read-only 09.00 – 10.00 UTC 24th June
Published by Matthew Revell June 23, 2009 in Notifications
Launchpad will be in read-only mode for an hour on Wednesday 24th June while we roll-out new code.
Going read-only: 09.00 UTC 24th June 2009
Expected back to normal: 10.00 UTC 24th June 2009
There’ll be a couple of minutes where Launchpad is unavailable while we switch into read-only mode. Keep reading this blog for details of the new release!
Importing translations and translation templates
Published by Matthew Revell June 18, 2009 in Translations
When you’re ready to start translating your project in Launchpad, there are a couple of ways to import your GNU Gettext translation templates (.pot) and translation files (.po) into Launchpad.
We recently introduced continuous imports from Bazaar branches or you can upload a tarball through the web interface.
There are, though, a few simple rules you need to follow to make sure your templates and translations are imported correctly. I’ve recently rewritten them to make them easier to follow and to add a few more tips for getting your templates right first time.
Read our translations import policy.
Launchpad’s bug import format
Published by Matthew Revell June 17, 2009 in Bug Tracking
Earlier today, Graham wrote about the Trac to Launchpad migrator.
In his post, Graham mentioned the XML schema we use as an interchange format when bringing a project’s bug history from elsewhere. It’s something that we knocked together to help projects when they move from other bug trackers. Although it’s still something that’s in development, you can use it as an intermediate format if you’re planning to import your project’s bug history from another tracker.
You can find the format, and also subscribe to get any updates if we make changes, over on the help page.
Making bug migration that bit easier
Published by Graham Binns in Bug Tracking, Cool new stuff
Greetings, readers!
For a while now I’ve been the Launchpad developer in charge of helping users of other bug trackers migrate their projects to Launchpad. We do this reasonably regularly for users of Trac, SourceForge and Bugzilla, and we’re always open to helping people migrate from other solutions should they wish to.
Several months back, the Elisa project migrated from Trac to Launchpad. In doing so, they wrote a script to take their Trac database and convert it to the Launchpad bug interchange format, which is an XML schema that we use for bug imports (you give us an XML document containing your bugs that conforms to the interchange format schema and we can then import it into Launchpad for you).
More recently, we realised that we were getting quite a few requests from Trac users for help with migration. We went back to the Elisa developers and asked if they’d be willing to let us have their migration tool under the GPL so that we could share it with everyone. They kindly said yes, passed the code to us under GPLv3, and yesterday I made it available on Launchpad as the Trac to Launchpad Migrator project.
It’s a bit rough around the edges at the moment and needs some documentation, but more than anything else it needs people to test it and use it so that we can make migrating from Trac to Launchpad as smooth as possible.
Update: Matthew’s written a blog post about our bug import format.
Launchpad offline 22.00 – 22.10 UTC 4th June
Published by Matthew Revell June 3, 2009 in Notifications
We’re taking Launchpad offline for around ten minutes from 22.00 UTC on the 4th June. This is to increase the document storage space available to Launchpad.
Going offline: 22.00 UTC 4th June 2009
Expected back: 22.10 UTC 4th June 2009
Note: Launchpad’s OpenID service will remain online throughout this downtime.
