Sinzui

The registry team is going to work on some long standing issues in the Launchpad bug domain. We are going to create a single page to configure the handling for projects. We have a draft of the proposed changes that shows that the bug expiration and remote project fields are subordinate to the choice of bug tracker. We need to revise labels and descriptions of the fields to make their purpose clear.

Proposed Launchpad bug configuration page

We intend to make it easier to locate a registered bug tracker by using to a lazr-js picker instead of a selection list with 700 trackers. You will also be able to register a new bug tracker at that moment. You will never have to find where the bug tracker list is and how to add a new one again.

Proposed Launchpad bug tracker registration overlay

I was migrating old CSS styles to Launchpads YUI-based style sheet a few days ago. I became lost in the new style sheet, and I was confused by what appeared to be duplicate or contradictory styles. I spent my evening reordering the styles by selector types instead of by application uses
When I was done I discovered we have several table styles that do not look like the intended style of the site. There are more than 10 list styles that imply the transitions to sprites is incomplete.

I think the decision to have sections for applications was wrong. It encouraged developers to create styles that are not reusable. Developers should be updating the styles so that all Launchpad evolves. (I recommended the continuance of this rule when I created the YUI style sheet.) The YUI style sheet is ridiculously large now, and it is only 9 months old. This is a strong indication that there are many exceptions in the presentation that users must learn.

My next round of changes will be to normalise the sheet to remove the duplication. I added a CSS reformatter and validator to gedit-developer-plugins to help me do this. After that, I think I need to reduce the number of classes by half, which also means updating some old layouts. There is still an unresolved issue of application specific styles in the old and new style sheet. I think a lot of work is needed to remove the exceptions from the pages. Doing this has one great advantage–future redesigns will require CSS and base template changes instead of changes to every template.

The Launchpad registry team has a zero-trivial bugs policy. Last year we observed that trivial bugs, though they are often low priority, they have the highest certainty to be fixed and are very visible to users. We decided that since an engineer can close 8 bugs in a day of work, there should never be more than 8 trivial bugs in the project.

I had a lot of meeting this week. I was too distracted to commit to working on a bug issue. I decided to start a branch that I could fix trivial bugs in between meetings. After a day of meeting, I had a branch that was ready for review.

We I say trivial bugs have the highest certainty to be fixed, I am referring to my own primer on bug triage. There is almost no risk in fixing the bug, and since we will know in an hour instead of days whether our efforts fixed the issue, trivial bugs have an intrinsic high priority. I really cannot say every trivial bug is high priority, but when I consider several of them together, they are high priority.

Most trivial bugs are grammatical errors, presentation issues, or navigation issues that do not stop users from accomplishing their task. Trivial bugs are obviously easy to fix, and users are reminded of them every time they repeat their task. These bugs are very annoying, they amplify the user’s perception of poor quality. Engineers can make a big improvement in user experience by fixing trivial bugs.

On Sunday I did an experiment to see how quickly I could provide the license information for old projects owned by the Registry Admins. There were 768 projects that I had the power to fix. Locating the license information is hard if you only know the upstream project. The copyright file in debian source package has all the license info, but I do not always know the source package (if there is one). There is a new feature on edge that suggests the Ubuntu package, and that makes this task much easier.

Reviewing a project takes 15 seconds. Linking the project to an Ubuntu package, providing a license, and reviewing the project takes 4 minutes. Some projects that are already linked to a package can be done in 1 minute. It may take 10 minutes if Launchpad suggests many source packages. I need to view the latest version number of each suggested source package in Lucid, and search http://packages.ubuntu.com/ to verify the version and description match the project and candidate package. I disabled a few projects because there was already a registered project with license information, and already linked to a package–I assume the project I was looking at was named differently from the package, so users re-registered it.

It will take me about 3 weeks to fix the remaining projects. That will still leave 4000 projects in Launchpad that are missing license information. I need to think of a strategy to get those fixed.

Today I fixed a bug where users could not link a project series to package in an older Ubuntu series. I reported the bug when working with Javier to clean up the duplicate glade projects registered in Launchpad. We both got oopses when we tried to fix the packaging links from the project’s packaging form. We fix them using the distro series packaging form.

I assumed the project version of the form was ignoring the submitted series; it always uses the current Ubuntu series. I wrote my test using the same situation that I experienced, and I expected a failure when I ran the test. I did get a failure, but it was not about the current Ubuntu development series. It was a database IntegrityError. I know that error!

Every morning, I read the oops reports from the many Launchpad process. Every exception and timeout in Launchpad is collated into a a daily report for the engineers to read. I report bugs for each problem that relates to the registry application. Most bugs I report from oopses contain enough information to fix the problem within a week. Last week I saw an IntegrityError in the oopses, but I could not reproduce it. So while I scheduled the bug to be fixed in the 10.04 release, I could not write a test it to fix it. I could not see that the IntegrityError was about a series different from the one the user submitted.

I got lucky today. The test setup creates all the objects in play. My bug from yesterday, and the bug from last week were the same bug that manifests itself in two ways depending on the state of the package in the current series. I marked the IntegrityError bug to be a duplicate of the bug I was fixing. The form was indeed ignoring the submitted distro series; it was a one line fix. If I had written the fix before the test, I would still be investigating the oops without a clue.

The Launchpad registry had a sprint in March 2010 to solve project registration issues. The topic was broadly set to be “drive through project creation”, but the goal was to allow a community to provide project information at the time of need. For example, a user wants to report a bug about a package in Ubuntu. The bug must be forwarded to the upstream project to be fixed. The user may need to provide the upstream project’s bug tracking information, and possible register the project in Launchpad first.

I talked about the madness of registering a bug tracker yesterday. Launchpad has many registered project without bug tracker information because there is no single simple page that allows a user to provide what is needed. I did a spike and could see that while we can collect the required information together in a single page, the information that the user must provide is not clear.

The disorganized information needed to configure a bug tracker.

Look at the picture. Can you tell that the “Remote project” field is subordinate to “In a registered bug tracker”? Bug expiration and reporting rules are subordinate to “In launchpad”. I still cannot register a new bug tracker from this page, not can I set the bug supervisor (upstream bug contact), or security contact. The bug tracker widget needs a rethink, and I suspect a model change is needed, because the logic in the view is representing a boolean field and a bug tracker field as four radio buttons. These is some zany logic trying to reconcile the states.

I do not anticipate us starting on the new widget for a few weeks, but Edwin did take a partial step by extracting the bug tracker information from the project’s +edit page. We will update the new page to be the single place that a user must visit to configure a project’s bug tracker and contacts.

This IRC transcript illustrates the pain of setting the upstream bug tracker, and the agony of defeat when you succeed.

<bac> sinzui: Remind me how do you set/determine the bug tracker for a project?
https://launchpad.net/ubuntu/lucid/+source/claws-mail shows one but i cannot find it on the project.

1. Visit the front page of Launchpad Bugs
   <bac> check
2. Follow the link to Bug trackers at the bottom of the page
3. Locate the (+) Register another bug tracker link at the bottom of the list of despair
   <bac> wait, there it is already in the list
4. Register the bug tracker and remember the name
5. Return to the project and follow the Change details link.
6. (Be sitting down for this), Select the new bug tracker from the list of despair
7. (optional) you may need to set the Remote project field with the ID of this project on its remote bug tracker.

<bac> Right, so if you go to https://bugs.launchpad.net/claws-mail you don’t see any mention that we know about the external tracker i knew it was bad but only anecdotally.

<sinzui> Yep. Weep at the madness. Good luck forwarding that bug upstream.

<bac> I don’t really have a bug. I just linked the claws-mail source package as an exercise and noted that the bug tracker was purported to be set.

<sinzui> My favorite part is that I have to claim that bugs are tracked in Launchpad so that I can set the bug supervisor, which is also the upstream bug contact role.

<bac> ewww

<sinzui> Launchpad can be a collective madness sometimes

Launchpad is often perceived to be a project hosting service. Some perceive Launchpad is a directory of packages in Ubuntu. Both views are incomplete and often lead to misunderstandings about how Launchpad can be used, and buy whom. I think the best summary of what Launchpad does is that it hosts open source communities.

From it inception, Launchpad strives to connect communities by lowering the barrier to make contributions to projects. Launchpad does not give any community exclusive control of a project or its parts. It is common to think of a project as being under the exclusive control of one community, and many services model that concept. The truth is more complicated. Successful open source projects often represent the work of many communities. Translators are interested in making all applications use their native language [1] so they need access to many projects. Users who support applications need to relate questions to answers, FAQs, and bugs. Distribution like Ubuntu need to know the bug tracker and the source code for every project who’s work is packaged.

Projects in Launchpad are more like places where communities meet to gather and share information. The communities provide bugs reports, patches, and translations to projects. Communities use Launchpad to learn where bugs are fixed, where the latest code is, what versions of the project’s work are available. Even if the project’s development community does not use Launchpad’s services, they can still use Launchpad to learn what other communities know and are doing.

[1] Accept for the Esperanto freaks ;)

I think the next bug for me to work on after hours is
bug #250103 [Teams cannot delete old email addresses]

This causes users and myself a lot of problems. While you can change a team email address in Launchpad, it never deletes the old one. It is kept and it is hidden so that it can never be reused. This is very annoying because users, not team own the address, so the user can never reclaim his address once he gives it to a team. This leads to a lot of requests to delete the address via SQL. This also prevents me from removing teams or their artefacts in my role as a Registry Administrator.

The right behaviour is to delete the email address when it is deactivated for the team. This is what the UI implies happens. Users can re-register the address when they choose to use it again.

This release replaces the snippet-based completer with a GTKSourceView-basedCompletionProvider.

• The python completer has rudimentary documentation in the info window that you can see using the Details button. This feature will be improved in future releases.
• Find searches application and xml files like javascript. Find was skipping some file types that gedit can edit that do not have the text/* mime-type.
• A bug that caused an exception when the syntax completer closed a tag is now fixed.

You can get the source or download a tarball at gdp in Launchpad

A debian package is available in a PPA