PPUApplication

I, James Hunt, apply for upload rights for the following packages:

  • friendly-recovery

  • libnih

  • mountall

  • upstart

Name

James Hunt

IRC Nick

jodh

Launchpad Page

https://code.launchpad.net/~jamesodhunt

Wiki Page

https://wiki.ubuntu.com/JamesHunt

Who I am

I am a developer working for Canonical in the Ubuntu Foundations Team. My main areas of activity are Upstart and associated boot technology.

My Ubuntu story

My involvement

I started working for Canonical on day 1 of UDS-N (25 October 2010). Previously, I'd been working as a Unix and Linux developer "behind closed doors" at a number of well-known commercial software houses.

I've been using Linux since RedHat 5.1.

Up until the year 2000, my entire career had been spent developing on Unix systems, initially via a dumb terminal talking to a SCO server, and then with Sparc and HP workstations. However, on my first day at IBM, I switched to a Linux workstation for all development and general activities and I haven't looked back.

In my early Linux career, I was using RHEL and Fedora almost exclusively: RHEL at work because customers were using it and Fedora at home so I knew what was in the RHEL pipeline. However, in 2007 I got frustrated with Fedora and switched to Ubuntu at home and fortuitiously was also able to switch to Ubuntu at work.

Examples of my work / Things I'm proud of

My contributions are listed here.

I've provided changes to 6 packages: http://launchpad.net/~jamesodhunt/+related-software

Areas of work

I am now the upstream Upstart maintainer after Keybuk handed this responsibility over to me.

I have also contributed to the NIH Utility Library, which is used heavily by Upstart.

For the P-cycle, I've spent a lot of effort working on the Upstart job logging feature. Superficially, this sounds like a relatively simple piece of work, but that view belies the reality:

  • Upstart had never written to any disk files before this feature was

    • added.
  • When Upstart starts, there is no writeable disk, and yet we want to
    • allow jobs starting in that early environment to have output logged

      as soon as disks become writeable.

  • Upstart knows nothing about disks and when filesystems become

    • writeable (that's mountall's job).

  • Users are using Upstart in myriad ways we hadn't originally
    • considered.
  • There are a lot of different code paths and failure scenarios to
    • code for and test.

When Keybuk and I dreampt up the job logging feature, we decided that it made sense to enable it by default (since if a job produces output, it is generally useful (as it's likely to be either debug or error output)). We have had a few bugs that escaped into the wild and affected users briefly, but once reported, we decided the best course of action was to temporarily disable job logging until we'd identified a fix to minimize the impact on users.

Things I've done to make development and testing Upstart faster, easier and more reliable:

Things I've done for users:

  • Written the Upstart Cookbook

    • This is still very much a work-in-progress, but the sheer size of the document already shows just how flexible Upstart is.

  • Wrote a tool called procenv

    • This dumps out everything about the process environment it runs in. Most of the information it produces is available via /proc, but this tool collates it all together and queries the data using system calls so would work on systems with no /proc. It was written originally to debug the environment the buildd's provide to the builds that run on them, but I intend to package this tool as it is a generally useful utility.

  • Wrote a tool called clone

    • This is a wrapper around clone(2). I use this for testing occasionally as it is more powerful than unshare(2).

  • Wrote a tool called out

    • This is like a cross between echo and printf and was designed to test the Upstart job logging code. I'm currently converting it to be UTF-8 aware which will make it more general purpose.

Things I could do better

  • Improve communication on Upstart activities.
  • Get more folks involved with Upstart.
  • Improve testing.

Plans for the future

  • friendly-recovery
    • Make it more feature-rich.
  • Upstart
    • Add support for user job logging.
    • Enable user jobs in Ubuntu.
    • Add full re-exec support (to allow Upstart to be fully restarted without a reboot).
    • Add 'chkconfig' type tool to make enabling/disabling jobs easier and programmable.
    • Interactive boot.
    • Write a file bridge to allow "start on file" conditions.
    • Overcome ptrace limitations and consider using cgroups.

    • Add new stanzas: mkdir, chown, chgrp.

    • Allow different signal to be specified for reload command.

    • Improve testability of boot and shutdown process.
    • Improve tooling around Upstart.
    • Improve Upstart documentation.
    • Improve Upstart build infrastructure.
  • NIH
  • Mountall
    • Consider merging this into Upstart to handle systems with no
      • initramfs.
  • General
    • Improve testing techniques and infrastructure to avoid bugs being released "into the wild"
    • Ensure that bugs which do occur are backed with new tests to avoid regression.

General

What I like least in Ubuntu

There are two areas that users may not ever need to consider directly, but which I believe are of paramount importance:

  • Documentation
  • Testing

Documentation

We're continuing to make good progress on Documenting some aspects of Ubuntu, such as the Ubuntu Packaging Guide, but I think we can do a lot more. Two examples are:

  • We need a fully comprehensive Server Manual

  • We need to provide further content on http://developer.ubuntu.com/,

    • for example on tools available for debugging and best practises for using these tools.

Testing

For a system as configurable and comprehensive as Ubuntu that works on so many different platforms, testing is always going to be a challenge. Great strides have been made this cycle to put the best infrastructure in place to allow us to improving our testing. There are of course many different types of testing so this is no mean feat. One problem area I have hit a number of times (ie regressions) is Thinkpad hibernate/resume so I'd like to see hardware testing on specific systems improve.

Comments

If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.

Endorsements

As a sponsor, just copy the template below, fill it out and add it to this section.

SteveLangasek

As the upstream maintainer of upstart and a member of the Canonical Foundations team, I can see no reason that James should not be given direct upload access for upstart and related packages (libnih, mountall). He has been primarily responsible for preparation of updates to the upstart package over the past year, and I think we're well beyond the point that sponsorship is simply a bottleneck. James is mindful of the importance of testing packages before uploading, and what bugs don't get caught in his testing don't get caught by the sponsors either. He also shows great prudence in requesting peer review for his changes even when not required for sponsorship, and I'm confident that he will continue to seek out his fellows in the Ubuntu community whenever he doubts the correctness of a change.

Specific Experiences of working together

James single-handedly delivered us working support for logging upstart job output this cycle, which has been a tremendous boon to the debuggability of Ubuntu system startup. I think he should be enabled to continue making such contributions to Ubuntu as effectively as possible.

Andy Whitcroft

I have worked with James a number of times particularly when debugging complex boot issues. He has always been knowledgable in his area and keen to help. Where changes have been needed he has shown a clear understanding of both the packages at hand and the processes for their update. He also shows a very sensible degree of caution a key attribute when changing these packages which can render the users system unbootable. He is also very good at reaching out to other people for (and with) advice and guidance when in any doubt, and for reviews of his changes. Highly recommended.

Specific Experiences of working together

I have worked with James on a number of gnarly boot issues requiring timely information and guidance as we tracked the issue through the boot process, he made himself available past the end of his day to allow us to get to root cause. When debugging issues introduced by his logging changes he was quick to spot the flaw and to propose fixes for the instant issue, but also went further and made the error handling more robust to prevent catastrophic boot failure in the face of any similar bugs.

Colin Watson

I've done a reasonable amount of sponsorship of James' uploads of Upstart and related packages. At this point I find that, aside from the occasional detail of bzr metadata, I'm simply uploading his changes unmodified, and am delaying matters more than I'm adding value. I'm entirely happy for James to be granted unsupervised upload access at this point, since he has effective technical ownership of these packages anyway and has been consistent in requesting review and testing where needed (often well beyond what I would have done myself).

Specific Experiences of working together

James and I worked on a terrifying plymouth bug together last month, which had previously utterly defeated several concerted attempts at reproduction and fixing; he demonstrated commendable persistence in the face of very difficult progress in setting up a reproduction environment, and his work on this was crucial in figuring out the problem and nailing down a fix which we could deliver both to Ubuntu users and to upstream.

TEMPLATE

== <SPONSORS NAME> ==
=== General feedback ===
## Please fill us in on your shared experience. (How many packages did you sponsor? How would you judge the quality? How would you describe the improvements? Do you trust the applicant?)

=== Specific Experiences of working together ===
''Please add good examples of your work together, but also cases that could have handled better.''
=== Areas of Improvement ===

CategoryPerPackageUploaderApplication

JamesHunt/PPUApplication (last edited 2012-05-09 19:09:40 by vpn-98)