I, James Page, apply for upload rights for the Ubuntu Server package set.


James Page

Launchpad Page

Wiki Page

Who I am

I'm James Page, based in Norfolk in the United Kingdom. After graduating from Aberystwyth University with a BEng in Software Engineering in 1998 I had a brief spell working for a UK defence company. I then spent the better part of a decade pushing an open source software strategy in a well know UK based financial services company. During this time I also helped develop and deploy a number of large, high throughput web applications using Java.

I now work for Canonical as a member of the Ubuntu Server Platform team.

My Ubuntu story

My Ubuntu story is quite short; I started using Ubuntu personally in late 2009 but I did not start to contribute to the project in any way until just before I started to work for Canonical in September 2010.

I've really enjoyed helping develop Ubuntu; I've always been a user of open source rather than a developer and I really like the different challenges this change brings. Specifically I've really enjoyed applying some of the Continuous Integration techniques I used when developing Java applications to automating the testing of Ubuntu ISO's and Ubuntu Server ec2 images (see below).

I think that I've been too shy about working directly in the Ubuntu development release. With hindsight working more directly in Debian/Ubuntu for the Jenkins packaging work (rather than through PPA's all the time) would have saved me time as I would have received earlier feedback on my packages and not had to spend so much time preparing work for upload (either to Debian or Ubuntu).

My involvement

My current areas of involvement:

  • Ubuntu Server Team.
  • Ubuntu Server ISO Testing.
  • Ubuntu Server ec2 Testing.
  • Ubuntu Java.

Things I'm proud of

Testing Automation

I really like doing things that save other people and myself time; when I first started working on Ubuntu I helped develop a framework for automatically testing ISO installations (started by Mathias Gug) into something that could be run automatically on daily basis using Jenkins during the development release. This has helped in a number of ways:

  • Early insight into install issues; testing installs on a daily basis for the current development release makes its quick and easy to see when it happened and identify the underlying issues when something breaks.
  • Time saved; although the server team does undertake manual ISO testing this is now constrained to the more complicated test cases that we have not been able to automate.

During the Natty cycle I re-wrote the ec2 testing framework originally developed by Scott Moser into a Python based project that could be used in a similar way for testing the Ubuntu AMI images for ec2. This has now also been automated using Jenkins and has enabled visibility of testing results in a way that the previous framework did not deliver.

Jenkins Packaging

This is still work-in-progress but is something I am proud of; during the Natty release cycle I successfully packaged Jenkins from source (albiet in PPA's - see my comment above on what I could do better). This involved packaging a large number of new Java dependencies and exposed me to a good cross section of packaging approaches for Java libraries.

Hopefully Oneiric should see this work in the Ubuntu archive; I'm working as part of Debian Java team to get the dependency chain and Jenkins into Debian so both distributions can benefit from this work; the nice side effect of doing it this way is that there are a larger number of Java packaging people in Debian which should enable better support in the long term.

Examples of my work

In addition to work on specific release deliverables and testing automation I'm also an active member of the Ubuntu Server team; I participate in the weekly triage rota and have tried to ensure that I work on areas outside of my specific area of expertise within the team.

Having upload permissions for the Server package set would help me support the wider Ubuntu Server team with SRU and bug fix activity.

I also keep an eye on anything Java related within Ubuntu; I try as much as possible to ensure that changes which are made in Ubuntu are reflected back into Debian to minimise the delta between the two distributions as much as possible.

Things I could do better

I think that I need to spend some time understanding open source licensing in more detail; I lack depth of knowledge in this area and any new packaging that I undertake would benefit from a better understanding of the compatibility of licenses etc...

Plans for the future


I want to ensure that the depth and complexity of testing undertaken on Ubuntu Server (and other variants) increases. I think the existing approaches and tool-sets get the project to a certain point; However we need to expand and complement the existing methodology; my specific interest is in complex deployment testing to ensure that the packages that we publish don't just work standalone; they work in complex deployment topologies.

I think the key to enabling this approach will be through use of tool-sets such as Ensemble and Orchestra to automagically build server deployments that can then be easily validated and tested.

See for some of my ideas.

What I like least in Ubuntu

Java; I'm aware that Java and Ubuntu don't always play nice and its not seen as a great fit (and TBH it's not) but Java is here for the long run and there are alot of popular applications that are not part of the distribution which are written in Java. I think that a few things will help enable Java further in Ubuntu:

  • Packaging automation; the toolsets (javahelper, maven-debian-helper) for packaging Java appear to have developed alot in recent years; however there is still alot that could be done to improve efficiency. I intend on working in this area when possible to improve the level of automation hence lowering the boundary for entry for packaging Java libraries and applications.
  • Educating upstreams; some of the issues around packaging Java relate to upstream behaviour in terms of breaking API compatibility or introducing new dependencies for minor version upgrades. I intent to try to work with upstream projects where possible to help develop behaviours which help Linux distributions in the long term.
  • Debian Java; TBH this is where most of the grunt work is done that enables packaging of complex applications for the distribution. I will continue to make efforts to participate through Debian Java where I can and ensure that Java works well across both distributions.

It would be great to get the Java tooling to a point where it's much easier to get complex Java applications into the distribution.


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

James has, since he began on Platform, been extremely helpful both in the server and in the testing arenas. His work on Jenkins and Java are exceptionally good (unravelling the Jenkins dependency nightmare, for example). I cannot sponsor him, not being a developer myself, but at least I can make sure his work is recognised by those of us doing testing. -- hggdh2 2011-06-07 14:18:17


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


General feedback

I've only sponsored a few of James's uploads to Ubuntu, but they've always been really well done. His attention to detail with patches and procedures is refreshing. In particular, James has tackled some of the problems with java packaging that many of us have been loathe to work on, and has done a stellar job. His recent packaging of Jenkins and its' dependencies is nearly legendary, and his PPA builds of etherpad had people calling his name on the streets of Budapest at UDS-O.

Specific Experiences of working together

See above for some general examples. Most recently, I sponsored and approved his SRU of OpenLDAP in LP: #783836.

Areas of Improvement

I can't think of anything, James has been stellar as a team mate and as a contributor to Ubuntu.


-- kirkland 2011-06-08 18:35:35

General feedback

James is just an amazing developer. He tackles hard problems and really solves them well. In particular, James has built some serious and unique expertise around Java packaging. This fills a huge gap we have within Ubuntu (and in Linux distributions in general). I've been extremely pleased with all of the work I've seen from James. Strong +1 from me!

Specific Experiences of working together

Perhaps most visibly, James was very much responsible for the availability of Etherpad at the last UDS in Budapest. Per resounding requests on the ubuntu-devel@ mailing list, I took a very naive, initial cut at updating some unattended packaging for the Etherpad project, and uploaded it to a PPA. In doing so, I CC'd James and asked him to take a look. James drastically improved the initial cut, ensuring that the various pieces built from source, installed properly, and worked well enough for UDS. I think the vast majority of UDS attendees preferred enjoyed the benefits of Etherpad.

Areas of Improvement


Dave Walker (Daviey)

General feedback

I have sponsored a number of James packages, they have all been of great quality. When I have raised a concern or suggestion for improvement, James has always welcomed the comments. James always seeks guidance when he is in doubt, and is comfortable knowing his limits.

The Jenkins packaging he undertook (currently mostly in PPA) was a massive undertaking with something like 50 NEW packages. James has been attempting to contribute his packages to Debian where viable. I thoroughly endorse this application for Ubuntu Server set.

James is a good egg.

Specific Experiences of working together

A few as an example of packages I have sponsored for James.:

We also worked together on the Etherpad packaging, and I was most pleased with his approach.

Areas of Improvement


Chuck Short

General feedback

I have also sponsored a couple of James' upload, they have all been great. When James doesnt know something he has always asked for help and if something goes wrong he is always open for feedback. The Jenkins and the Etherpad packaging for UDS makes one want to do ascii art:

/ JAMES PAGE could save your system      \
\ he should be a ubuntu-server-dev       /
       |o_o |
       |:_/ |
      //   \ \
     (|     | )
    /'\_   _/`\


General feedback

If you hardly noticed I left the Server team, James Page is the main reason for it. He took over the difficult art of Java packaging, with more skill and energy than I ever had for it ! This art forces you to touch lots of different areas so you can become a true ninja in no time. But he also went beyond Java and touched a lot of non-Java server packages as well.

Specific Experiences of working together

I sponsored a lot of James work regarding Java packaging. The work was always perfect, and often more maintainable than what I would have done myself. He is a perfectionist, and those make good distro developers.

Areas of Improvement

I heard Chuck Norris may be physically stronger, and Bruce Schneier may decrypt RSA faster. But that's about it.


General feedback

Looks fine. James is doing solid work planning and actually doing the packaging for large stacks of java applications/libraries. Sponsored packages usually were fine for uploads, patches and packages are forwarded to Debian.

Areas of Improvement

Maybe should get used to touch OpenJDK6/OpenJDK7 ;-P


=== 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 ===


JamesPage/ServerDeveloperApplication (last edited 2011-06-14 13:33:27 by dslb-088-073-095-180)