Planet Launchpad

I gave a presentation for Ubuntu App Developer Week this week about using gedit for development. I use gedit to write python apps ranging from the enormous (launchpad) to the tiny (pocket-lint) You can read the PDF of gedit-developer-plugins summarising my presentation (and it includes pictures).

I updated my Macbook to OS X Lion over the weekend and had a nasty scare. I could not boot back to Ubuntu, nor could I see my Ubuntu partition. That is the moment where you think, “Is everything baked up? What will I loose?”. I remember that I switched from Evolution to Thunderbird last month; my email was lost. The truth is that everything was okay, and if this happens to you, you can fix this in a few minutes like I did.

I do not know what the OS X installer did. Maybe it resized the partitions. rEFIt did not report an issue. It verified that the the partition tables were synced. Grub did not know about Ubuntu though. I saw the grub prompt (grub>) instead of a message about the selected partition. I followed ubuntu mactel instructions to install Ubuntu, so I know Ubuntu should be on located on hd0,3. I typed:

grub> root (hd0,3)

grub> find /boot/grub/stage1

Find will report if it finds the boot information. If it does not find stage1, then you can try an alternate disk and partition, such as root (hd1,1) or root (hd0,4). When you find stage1 you can configure grub to fix boot:

grub setup (hd0,3)

I restarted and Ubuntu booted correctly. No data was lost.

The reason that OS X could not see my Ubuntu partition was because MacFuse was compiled for 32bit. Lion is 64bit. I installed the 64bit version of MacFuse to see Ubuntu and my data.

Or: “Why I don’t classify bugs as medium”

The process of triaging issues (bugs, features, and tasks) has one crucial principle: Prioritise the work according to need and certainty.

Work is prioritised because there are not enough engineers to do all the work. Some features will never be completed, some bugs will never be fixed. Triage determines which bugs can and will be fixed, which features can and will be implemented. Need is generally understood, when planning work, but certainty is not, and that often leads to wasted work and unmet expectations.

By need, I mean a measure of severity. What percentage of users does the issue affect, and how severely does it impede them from completing their task.

By certainty, I mean a measure of how certain the engineers are that they can address the issue. Time is also a factor in this measure, the longer an issue takes to address, the more likely that the conditions that were first judged will change.

The act of triage is separating work into groups that are being worked on now, next and last. There can only be as many “now” bugs or features as there are engineers. The number of “next” work is limited to the velocity of the engineers and how infrequently plans change. The bugs that are last will probably never be addressed, the last features may never be started.

The corollary to this rule is that there are a finite number of bugs or features in the first two groups. There cannot be more work in these groups than there are engineers to do for the given period of time; otherwise the engineers, businesses and users are being misinformed about when issues will be addressed.

An Example

Consider there is one engineer and two bugs. He can only work one bug at a time. One bug is more important than the other. The risk is that he may not be able to fix one of the bugs before users are disappointed and abandon the application. He risks disappointing all users if he does not fix either bug because he choose the one with the most need over the one he was certain he could address.

If he does not know how to fix the bug with the most need, or that the fix takes a long time, he is wasting time he could have spent fixing the bug with more certainty. The only way he can address the bug with the most need is to employ a hack to reduce the need, to meet the expectations of some users. The hack is also used to gain time to understand the problem, thus increase certainty.

Only Assign Work that You Are Committing to do in the Near Future

When a work is assigned to an engineer, he is committing to complete the work in the near future. What the “near future” means is different for each project. I suggest 3 releases is the “near future”, because when work is planned, the engineer is thinking about now, next, and last. For some projects this period might be 6 weeks, for others, 6 months.

I prefer to plan for the current release, and the next one. As work is reprioritised, it may be rescheduled to the third release. I do not think it is wise to plan a bug or feature to be completed in the third releases because if it slips to the fourth or fifth released, I doubt the it was correctly prioritized as high.

Any high work that is assigned to a engineer for more than 3 releases was not high. If it were, the work would have been reassigned to someone who could complete it in the scheduled time. Any other work that is assigned for more than 1 release is also misprioritised. You are lying to yourself, and the the project’s users, when you assign work that you are not committing to fixing.

Practical Classifications of Importance

Work is often classified in relative terms. It is better to classify work according to how it are managed to convey when and under what terms the bug will be fixed or a feature will be complete. There are three priorities that work can be classified as:

Critical

The bug dramatically impairs users. Users may lose their data. Users cannot complete crucial tasks. The feature is needed to encourage adoption or prevent abandonment of the project.

Synonyms: required, essential, now, must do

The work is immediately assigned to a engineer. It is his top priority to fix. Team members help the engineer to plan and do the work. The work is released as soon as it is deployable; in the case of a bug, it is released outside of the release schedule.

High

The bug prevents users from completing their tasks. The feature provides new kinds of tasks or new ways of completing tasks.

Synonyms: expected, next, can do, should do

The work is assigned to a engineer to be completed in the next 3 releases. The engineer may choose to do other work if he believes it is within the scope of the high priority work.

Medium

The bug is inconvenience for many users. The feature provides new ways of completing tasks.

Synonyms: preferred

The work is not scheduled, though it is intended to be completed. When the work is assigned, it may also be scheduled, but there is no commitment to complete it for the stated release. The engineer may choose to postpone the work in favour of more important work.

Low

The bug is an inconvenience to users, but it does not prevent them from completing their tasks. The feature is a convenience to users.

Synonyms: optional, last, may do

The engineer may assign the work to himself while working on a high priority work because the high work provides an opportunity to complete the low priority work at less cost. If the low work in any way jeopardises the high priority work, the low work is unassigned. The engineer is thus certain that the work can be fixed quickly and without difficulty. A corollary to this rule is that low work that is assigned to a engineer must be “in progress” or “fixed” states.

The Problem with “Medium”

It might be argued that when the engineer has an opportunity to fix a low or a medium bug, he must choose the medium one. This rules does not define a practical distinction between medium and low. There is no commitment to fix the medium bug; it will not be scheduled for fixing. A engineer chooses to undertake a low bug because he sees an opportunity to fix it while working in the affected code. The engineer is choosing to do unscheduled work because he is certain it does not jeopardise his scheduled work. The engineer might see an opportunity to fix a medium and a low bug at the same time, but that is unlikely.

It can also be argued that ‘critical’ is ‘high’ and that ‘high’ is ‘medium’. True, that is a matter of semantics. The crux of the issue is that there are three practical classifications of work. The words chosen to describe the classifications could use the tofu scale of hard, firm, and soft. People who are unfamiliar with triage will appreciate names that convey the kind of attention the issue will receive.

Some teams with a large number of bugs prefer to keep a pool of medium work from which releases are planned. Items in the pool may be escalated to high if it is perceived that once work is started, there should be a commitment to complete it as scheduled. This work is different from low work because the work makes a substantial improvement to the application, but like low, there is no commitment when the work will be completed. It can be argued that work starts on medium bugs and features because of changes to other priorities, certainties, or the number of users it affects.

Consequences of Misprioritised Work

Stakeholders often use reports that list the prioritised work for a release and for each engineer. When work is misclassified there are two commonly observed consequences: a decreased in certainty, and a decrease in communication.

In the first consequence, the engineer’s effort may be wasted; there are issues that have more need and certainty. Engineers, and other stakeholders, are often tempted to complete the misdirected work after the misclassification is discovered because it is assumed that it is better to always deliver something finished than nothing at all. This is a risky choice, because it jeopardises work in future releases. By working on less important work, the engineer is decreasing the certainty of the more important work.

The second consequence is that the engineer ignores the list and he works on issues according to some other source, such as the opinion of another stakeholder. While the engineer is working on the correct issue, it is unclear to other parties what work is going on and when will it be completed. Users may abandon the project in frustration. Planners cannot coordinate all the stakeholders.

The first consequence is possibly a failure to do re-prioritisation during the triage process, but second consequence is a total failure in the triage process. Why would anyone do triage if the prioritisation will be ignored? How can work be coordinated if the work is unknown to all stakeholders? Why would users trust a project if it does not do what it says it will do?

Work must be reprioritised during the triage process to ensure that engineers are working on the issues with the most need and certainty. Engineers must work from the list or prioritised issues.

Indicators of Misprioritised Work

The rules of practical classification provide tests for misprioritised bugs, features, or tasks.

• The work is critical, but it is not assigned and targeted for release.
• The work prioritised as high, but it is not assigned and for a release.
• The work is high, but have not been worked on in 3 releases.
• The work is low and unassigned, yet it is targeted for a release.
• The work is low and assigned, but the engineer is not working on it.
• The work is considered to be triaged, but it’s priority is not critical, high, or low.
• An engineer is assigned more work than he can accomplish in 3 releases, and it cannot be reassigned.

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

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.

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

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.