||'''Contents'''<
><>|| ''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 [[FoundationsTeam|Ubuntu Foundations Team]]. My main areas of activity are [[http://upstart.ubuntu.com|Upstart]] and associated boot technology. = My Ubuntu story = == My involvement == I started working for Canonical on day 1 of [[http://summit.ubuntu.com/uds-n|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 [[http://wiki.ubuntu.com/JamesHunt|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 [[https://launchpad.net/libnih|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: * Wrote [[http://people.canonical.com/~jhunt/upstart/utils/upstart_menu.sh|upstart_menu.sh]] ([[http://people.canonical.com/~jhunt/upstart/utils/upstart_menu.png|Screenshot]]) This allows me to build and install a new upstart binary, reboot and have it automagically appear at the top of a friendly menu-based tool which saves fiddling around with grub command-lines. * Added a number of command-line options to upstart to simplify testing. Notably, it is possible to run Upstart as a normal user for testing purposes which makes life a lot easier as you don't need to debug the boot - you can just run Upstart via gdb. See * http://manpages.ubuntu.com/manpages/precise/en/man8/init.8.html * http://upstart.ubuntu.com/cookbook/#command-line-options * Set up a few PPA's to glean feedback on new builds from users: * https://launchpad.net/~jamesodhunt/+archive/upstart-testing * https://launchpad.net/~jamesodhunt/+archive/upstart-job-logging * https://launchpad.net/~jamesodhunt/+archive/stuff-and-nonsense * I now use LXC containers quite a lot for preliminary Upstart testing due to the extremely fast "boot" speed which reduces debug cycle time. * I've almost finished writing an enhancement to the NIH unit test facility used by Upstart: This will allow individual Upstart tests to be run. There are currently over 1,000 tests and debugging a single failure is very time-consuming for a variety of reasons. [[http://people.canonical.com/~jhunt/nih/test_feature_macro_improved.c|Proof of concept]] * Created a [[https://code.launchpad.net/~upstart-devel/+recipe/upstart-daily|Daily build packaging recipe]] for Upstream Upstart so that any changes I make can be automatically tested for the Upstream Upstart project. There is a current build failure, but this appears to relate to the way the buildds are configured (currently being investigated). * Wrote a [[http://people.canonical.com/~jhunt/upstart/testing/cartesian_product.py|Cartesian Product]] utility. This generates mathematically all possible combinations of Upstart jobs, scripts, log output, etc. It actually output Upstart jobs but currently generates so many it just isn't feasible to run the complete set of tests! I'll be looking into the possibility of running these tests for the next cycle. This tool uses my `out` utility (see below). Things I've done for users: * Written the [[http://upstart.ubuntu.com/cookbook/|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 [[https://code.launchpad.net/~jamesodhunt/ubuntu/precise/procenv/trunk|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 [[https://code.launchpad.net/~jamesodhunt/+junk/clone|clone]] This is a wrapper around [[http://manpages.ubuntu.com/manpages/en/man2/clone.2.html|clone(2)]]. I use this for testing occasionally as it is more powerful than [[http://manpages.ubuntu.com/manpages/en/man2/clone.2.html|unshare(2)]]. * Wrote a tool called [[http://people.canonical.com/~jhunt/utils/out.c|out]] This is like a cross between [[http://manpages.ubuntu.com/manpages/precise/en/man1/echo.1posix.html|echo]] and [[http://manpages.ubuntu.com/manpages/precise/en/man1/printf.1posix.html|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 * Include test enhancements (See Bug Bug:933717 and [[http://people.canonical.com/~jhunt/nih/test_feature_macro_improved.c|test_feature_macro_improved.c]]. * 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 [[http://developer.ubuntu.com/packaging/html/|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 [[Bug:553745|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 == {{{ == == === 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]]