Sinzui

I recently investigated some spurious errors running some locale tests. The tests failed because there was no page title, which may come from an obsolete pagetitles module, or from the view class. Reading the source code side tracked me for an hour and I cannot get it out of my head, so I think need to write about the immediate and root issues.

There is a mechanism to fall back to a form’s label when the page title is not provided, but not every page is form. I can see in the rules that many pages really do require a property to provide the page’s heading (The h1 element) and something to provide the first item in the page title. Bread crumbs are the reversed page title, so page_title is also the last bread crumb. This is bad because many views define one property to be identical to the other, eg page_title = label. I reported a bug last year about cases where we need to do this because I was informed it was not necessary. The code clearly states page_title is required. Only 3 lines are needed to avoid defining identical properties in view classes, fixing this issue would not fully satisfy me.

The Launchpad 3.0 header is still a root problem for page headings, bread crumbs, and page titles. When the heading and the last bread crumb are the same, redundant information makes the top of the page hard to read. It looks wrong. It really is wrong, but not according the Launchpad’s header rules. In general, Launchpad should not generate redundant headings, or encourage engineers to create redundant headings.

We sometimes want the view’s h1 heading to be different from the last bread crumb because it is not clear what is being edited. The problem is most clear when you are looking at deep pages where the context object is not the branded project/distro. For example:
https://launchpad.net/ubuntu/maverick/+source/wsjt/+changelog

The heading cannot be “Change log” because seen under “Ubuntu”, the user will pause as ask “what the …?”. We use a label to clarify the Change log is for a secondary context “”"Change logs for “wsjt” source package in Maverick”"”.

It may be possible to drop the either the page_title or label properties if the header was redesigned to show the immediate context before the action/view that the user is seeing. For example:

This suggestion is fatally flawed of course because it does not consider the Launchpad applications (bugs, code, …)

Have you ever tried to register a project for a source package in launchpad? You probably wanted to locate the upstream bug tracker or get the latest code. You were probably thinking that Launchpad has a lot of the information. You could copy some information from the package, then add the repository and bug tracking information. Isn’t it hard?

My team have discussed adding a drive-by-project-registration for months, but we still cannot provide the information needed to register a project. The project registration form asks for a description and licenses, but this information is not presented in Launchpad. I know every Ubuntu source package has a description and it cannot be in one the Ubuntu’s repos without a copyright file.

This package is listed on the first page of packages that have bugs that need forwarding to an upstream project: /ubuntu/maverick/+source/wsjt

What is it? What are its licenses? I do not know how to answer these questions using launchpad. When I need to register an upstream project in Launchpad, I use packages.ubuntu.com. It allows me to search for a source package, shows me the description and has a link to the copyright file. The copyright file often has the project home page listed too.

I created a proposal to change Launchpad to provide this information so that it is easy to answer questions about packages and register projects for them: Essential Source Package Information

I have been doing a lot of work in the Launchpad bug tracker recently. Reading bug reports and code remind me of my own frustrations using the Launchpad bug tracker.

Bug reports include deactivated projects. I have seen bugs that affect more than one project, and one is deactivated. I get a 404 when I navigate the link. No website should be making dead links to itself. Surely the fix is just a few lines to filter out deactivated projects.

I cannot change the affected project to a distro and source package in a bug report. I can add a distro, but that does not remove the bug from the project. The project’s bug team will get irrelevant email forever. I get a lot mail that is not about my projects. One frustrated user created the “null” project that anyone can reassign these bugs to. This is wrong from Launchpad’s perspective, but even I use the “null” project because the level of email is a serious hindrance to using Launchpad. The Launchpad Answer tracker lets me change the question from a project to a distro, why can’t Launchpad Bug tracker do the same?

Owners of projects are sent bug mail when the project does not use Launchpad bugs. WTF? Launchpad mailing rules fall back to the project owner if the bug supervisor is not set. The rules never check if the someone explicitly set that Launchpad is used for bug tracking. That is in sane. This is a contributing factor to why users complain about too much mail. This is also the reason you cannot contact the Registry Administrators team; their email address is never checked because it is filled with bugs reported about Fedora and Gentoo…which do not use Launchpad.

I do not understand bug nominations. Every one I have seen appears to be made by a user who thinks he can vote for a low priority bug to be fixed in a development series. I have even seen trunk series nominated, though it will never be released. As a release manager, I use priority as my guide to planning fixes. Open source development is not a democratic process. The only use case I can imagine for bug nominations is in super large projects like Ubuntu that have too many high priority bugs. The project has a small team of release managers and a large team of project drivers that need to select candidates for the release. If Launchpad must have nomination, the feature should be restricted to project drivers.

The road to failure is paved with bugs targeted to series. I advise everyone to never target a bug to be fixed in a development series because you cannot undo your mistakes. The action creates a conjoined task to the series. You cannot delete it, you cannot change the series it affects, and it blocks you from updating the bug in the project or distro. Since the bug tasks cannot be removed, Ubuntu has hundreds of bugs targeted to obsolete series that will never be fixed; its bug listings are lies. I recommend creating a milestone without an expected date for the series. Target bugs to that milestone, you can change your plans and update your bugs as needed.