Sinzui

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

There has been a interesting discussion about localizing standard directory names for applications on GNOME’s desktop-devel-list. The discussion is under the ‘Call for a Gnome Media Center‘ thread. There is a lot of well meant suggestions about mapping a Music folder to another name.

I don’t think this is a GNOME problem though. This is a desktop problem, a distro problem. Users want their apps and data to work in their language, and those apps come from a lot of projects. No one is happy when a lone app like Firefox, OpenOffice, or Quanta insists that a specific directory name exist. I think we need a concerted effort at freedesktop.org to define how apps locate a standard directory where data is stored. By concerted, I mean settle on a simple standard that can be implement in less than 100 lines of code by the major desktop projects/apps. Distros might want to put some labor behind the effort to see that key apps are updated in time for distro’s next upgrade.

Localization of diretories, is more that just language, it’s the user’s perception of the data. Ubuntu Edgy 6.10 switched to F-Spot for photo management. F-Spot is a great application! I’ve been building it for years now, so I wasn’t put out by making a few changes to it so that it uses my ‘Camera’ directory. My wife Anne was not pleased though. She refused to use it because it wanted her ‘Pictures’ folder renamed to ‘photos’. I think she was taking a pretty draconian position considering the benefits she got by switching to F-Spot. I found a compromise by using a poorly documented feature of nautilus. If you have ever read the source for nautilus (because I’ve never seen a document or announcement about this), you may have come across the ‘.hidden’ file. Nautilus will not display any files or directories listed in a directory’s ‘.hidden’ file. I believe this feature was created in response to a few apps like Java that were littering $HOME with files needed only by developers. Apple’s finder has a similar feature, though I don’t believe it is configurable like Nautilus’. To fix my wife’s desktop I opened the terminal and

ln -s Pictures photos
echo "photos" >> .hidden

F-Spot uses the photos symlink, Anne sees her Pictures. Anne is not a command line user; it might be years for her workout what I’ve done.

This solution could go a long way for GNOME GUI users. It is not good for command line users, and it does require some admin experience to setup and maintain. I suspect a simpler and robust solution would require the app (or platform lib) to check a dot-hidden file that maps standard to locale names. Regardless of how the platform stores is configuration information, the publication of that information must be backward compatible, and easy to implement for older or non-platform apps–hence a dot-hidden file in the $HOME directory. I’m sure the solution is not that simple; some apps cannot handle unicode still.

Firstly, let me apologize to everyone who has heard of the birth from others instead of Anne or myself. We have had a very hectic two weeks, and have had little time for anyone but our children.

Tristan Alexander Lawrence-Hovey was born on January 9, 2007 at 5:58 EST. He weighed 7lb 13.8oz in anachronistic measuring units. He measured 19.25in in length (also in old units). He inherited my hair, nose, ears, and toes. From Anne, he got his eyes and mouth. He appears to have a calm disposition like Caroline (another trait that must come from Anne). I added a gallery of photos from Tristan’s birth, and made a short slideshow of the birth (you can save any high-res photo or the QuickTime movie by choosing ‘Save As’ from your browser’s ‘File’ menu).

Tristan was taken to the Neonatal Intensive Care Unit a few hours after birth because he was having difficulty breathing. Nothing conclusive was found to be the cause, and he was breathing fine a few hours later. The doctors decided to begin a seven-day course of antibiotics while they continued to test. He was moved to the half-way room two days later, where we were permitted to hold him. We visit him for most the day. Anne is nursing/feeding him as best she can given the awkwardness of the situation. I spend a lot of time moving Anne and the children to and from the hospital and schools. The hospital will release Tristan Tuesday evening, pending the completion of his medications and his hearing test. I prepared some photos from Tristans stay in the NICU and a QuickTime slideshow of the past week.

PS. My only disappointment was Anne rejected Euphrates for a middle name. I have some solace in the knowledge that his full name in iambic pentameter.

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

My group is rebuilding one of our websites, and the UI is getting some serious attention. The business and technical groups came to an early decision that we would not be using multi-select listboxes. They alway require special instruction to use, and they are difficult to use for many users. I don’t know how long that MacOS has supported this feature. Windows has had the feature for more than 15 years. GTK has a similar behavior in the treeview. But Why, oh why, are we perpetuating such a bad solution.

We use radio button for mutually exclusive options, and checkboxes for inclusive options. I have no issue with the listbox to restrict the view of a large list, but why change the rules of the exclusive/inclusive operation? The problem is the size of the list, not how the user interacts with it. The listbox could, maybe should, display exclusive items as radio buttons, and inclusive items as checkboxes. The user should know by the presentation of the items in the list how the listbox will behave.

Using GTK’s treeview to implement the behavior doesn’t take a lot of work–just add use a radio button or a checkbox instead of text, and ignore the SELECTION_MULTIPLE property. Putting the checkboxes/radio buttons in a scrollpane is even easier to implement. regardless of the implementation, all listboxes in my GNOME/GTK desktop should behave consistently.

Until I thought about this matter I had not noticed that Gecko/gtkmozembed is forging a listbox control for GTK. Since the listbox was removed from GTK few years ago, Gecko must be using a its own widget to imitate the missing behavior. Still, this behavior, while consistent with other OSes, it is not consistent within each OS. I’m considering using a div with fixed dimensions and overflow to fix the behavior. I’m somewhat uncomfortable introducing non-standard UI behavior, particularly to a Web browser. But I feel that things are so broken, that it would be negligent of myself and my group not to take some action.

To anyone who has any influence of the Mac/Windows interface, please help end the control-click to select madness.