Launchpad: persia

Current Activities

I'm a member of the Debian Games, Ubuntu Studio Developers, Ubuntu Japanese Team, Ubuntu Mobile Developers, Ubuntu Java, and Ubuntu Universe Sponsors teams. I have interest in package maintenance, bugfixing, reviewing QA tools, and process discussion. I'm a member of the Developer Membership Board, with interests in process scalability and developer identity. I'm also a member of the Asia&Oceania Regional Membership Board, and try to encourage cooperation between different groups and teams within Ubuntu.

A summary of some of my past activities is also available.


I'd like to get better and more comprehensive automated developer-focused QA tools, both to improve the state of the packages, and to help in sharing improvements with Debian to reduce duplication of effort. I'm interested in improving integration of community provided patches, workarounds, and solutions to leverage the ever-growing body of expertise to improve the distribution. My current development goals include a richer joystick experience, wider application support for armel, a BCI X driver, and a sane framework to support using multiple computing devices within the same computing context (mostly handheld+laptop for now).

Areas of Interest

My primary development interests include audio (especially audio generation and manipulation tools) and input systems. I dislike things crashing, and am happy to help debug nearly any crash or code-traceable unexpected behaviour. I'd also like to be able to find everything in the menus, which keeps the stdout spew in ~/.xsession-errors, where it belongs. I use daily the amd64, armel, and powerpc ports of Ubuntu, and wish to keep them well supported. In an ideal world, I'd be able to use Ubuntu as part of an Augmented-Reality system, with magnetic manipulation of my optical nerves for display, and alpha-wave analysis for input.


I first encountered C and UNIX on an HP/UX system in 1984, and switched to UNIX as a primary home computing environment with SunOS 4.1.3_U1 in 1991. I started using Linux with Yggdrasil in 1993, first started using Debian with Potato pre-release, and first started using Ubuntu shortly after the Warty release.


.desktop files

It is important for all packages that are intended for GUI launch to contain .desktop files. These currently serve two purposes, firstly they are required for the target applications to be displayed in the menus, and secondly, both adept-installer and gnome-app-install depend on the presence of .desktop files to determine whether an application is a target for installation. Please visit PackagingGuide/SupplementaryFiles and make some .desktop files.


The ideal way to refresh config.{sub,guess} for each build is to build-depend on autotools-dev and use CDBS, debhelper (=>7), or the following debian/rules fragment:

        cp -f /usr/share/misc/config.sub config.sub
        cp -f /usr/share/misc/config.guess config.guess

        rm -rf config.guess config.sub

There are, of course, several cogent arguments against doing this, but if you choose not to update for each build, please do not attempt to automate the update process by altering debian/rules or build-depending on autotools-dev

Native package versioning

In Debian, native packages are versioned as package-version (rather than package-version-revision used for non-native packages), and NMUs are versioned as package-version-0.N (where N is the number of NMUs since the Maintainer last uploaded). I believe that Ubuntu ought to version Ubuntu changes to Debian native packages as package-version-0ubuntuX (where X is the Ubuntu revision number). This allows for seamless merge with Debian NMUs. If this is not done, when native-1.2 is updated by ubuntu, it becomes native-1.2ubuntu1, which is larger than native-1.2-0.1, so that the package may not be synchronised if the Ubuntu changes were adopted, and Ubuntu must create native-1.2ubuntu2 to process the changes (as native-1.2-0.1ubuntu1 is also a lower version than native-1.2ubuntu1).

Maintenance isn't limited to packaging

Software has bugs. This is unavoidable. When there is a bug, it should be fixed. As maintainers for Ubuntu, this means we should patch the bug. If it is an upstream bug (where upstream may include Debian), passing the solution upstream is best, as that increases the chances that we don't have to maintain the patch, but leaving the users affected is not preferable, if it can be avoided.

Packaging style

Packaging should be done with the goal of making it as simple as possible for someone else to understand the packaging. Try to reduce the size of debian/rules as much as possible. Make sure that any wrinkles are well-described in debian/README.source. Unless you're building something for which it is impossible, use every debhelper support script you can find, rather than inventing a special-case solution.


EmmetHikory (last edited 2010-03-05 03:35:49 by persia)