CoreDevApplication

I, James Page, apply for Core Developer, with additional membership of MOTU

Name

James Page

Launchpad Page

http://launchpad.net/~james-page

Wiki Page

http://wiki.ubuntu.com/JamesPage

Who I am

I'm James Page, based in Norfolk in the United Kingdom. After graduating from Aberystwyth University with a BEng(1st) 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

I started using Ubuntu in late 2009 and have been contributing as a developer for the last 12 months. My contributions have mainly been server related with a particular focus on Java.

I already have upload permissions for the Server Package Set - see JamesPage/ServerDeveloperApplication for details of my application in June 2011.

My involvement

My current areas of involvement:

  • Ubuntu Server Team.
    • Bug Triage
  • Automation of Ubuntu Server ISO Testing.
  • Automation of Ubuntu Server ec2 Testing.
  • Ubuntu Java Maintenance.
  • Member of Ubuntu Bug Control
  • Packaging of Jenkins and Octopussy during Oneiric.

I've just started participating the the Patch Pilot scheme and intend todo this regularly. Having either core dev or MOTU would help out alot with sponsoring other contributors work.

I ran an UDW session on packaging Java libraries with Maven2 in July this year (see https://wiki.ubuntu.com/MeetingLogs/devweek1107/JavaLibraryPackaging).

I'm a member of the debian-java team; I try to ensure that all of my packaging work/fixes/etc gets fed back to Debian as well as landing in Ubuntu. I also maintain a number of packages in Debian (see My Debian QA pages - here and here)

Things I'm proud of

Jenkins Packaging

Jenkins landed in the Oneiric archive after about 8 months of work; it was a challenging piece due to the large number of dependencies (see above) and the various different build tools that each of the packages used!

After doing some initial packaging in PPA during the Natty release I was able to refine the dependencies required by patching out various bits of non-Linux native integration which has helped reduce the effort of getting this work into the archive.

I've enjoyed working with the project founder, Kohsuke Kawaguchi, who has been very responsive to updates that I have requested (mainly due to missing licensing and copyright information) and has fully supported getting Jenkins into Ubuntu as an alternative distribution model.

There are some libraries that are not ideal in the chain - the Jenkins project maintains a number of forks of other libraries that are already packaged. However this is what was required to get a complete Jenkins package for Ubuntu. I intend to work upstream to help push back jenkins fork changes into the parent projects longer term so that we can potentially remove some of these forks from the archive.

I've been working to contribute this back into Debian as well (indeed some of the packages I completed earlier in the Oneiric cycle went to Debian first) - this is still work in progress in conjunction with the debian-java team with around 15 packages or so still to be accepted.

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.

Both of these frameworks are used and actively developed by the Ubuntu QA team to perform regular/daily testing of the current development release (see http://jenkins.qa.ubuntu.com for the current test results).

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.

jenkins
jenkins-test-annotations
jenkins-crypto-util
jenkins-executable-war
jenkins-memory-monitor
jenkins-task-reactor
jenkins-dom4j
jenkins-xstream
jenkins-json
jenkins-trilead-ssh2
jenkins-winstone
jenkins-commons-jelly
jenkins-commons-jexl
trilead-putty-extension
jellydoc
metainf-services
args4j
access-modifier-checker
annotation-indexer
bridge-method-injector
stapler
maven-stapler-plugin
maven-hpi-plugin
stapler-adjunct-timeline
libpam4j
robust-http-client
sezpoz
tiger-types
txw2
localizer
maven-antrun-extended-plugin
jcaptcha
akuma
octopussy
python-jenkins

Things I could do better

What I said when I applied for Server Package Set permissions

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

Having now had a number of packages accepted into Debian and Ubuntu I have feel I have developed in this area; the Ubuntu Core Developers and Debian Developers who have sponsored my work pointed out some Licensing issues that I have managed to get addressed in the upstream projects I work with. This has helped me think in the right way when analysing and documenting copyright and licensing.

Plans for the future

General

Hadoop Ecosystem

The status of Hadoop and its kin in Ubuntu has fluctuated a-lot over the last 12 months; Hadoop itself has been dropped from both Ubuntu and Debian and Zookeeper was orphaned (now has a new owner - ME) in Debian.

I see this as a key part of the Ubuntu Server offering going forwards and I'm really uncomfortable with this uncertainty.

Some of this has come from upstream; the Cloudera patchset and packaging is very popular and I think this has generated contention with the packaging in Ubuntu and Debian.

My approach to resolving this is two pronged:

  1. I am a committer on the Apache Bigtop project (http://incubator.apache.org/bigtop/) which is the transfer of the Cloudera packaging project to the ASF; I hope to help drive direction with the upstream packaging to help enable better distribution packaging in Ubuntu and Debian.

  2. Adoption of packages in Debian (and Ubuntu); I have already picked up the maintenance for zookeeper and I intend to pickup hadoop plus start packaging other parts of the hadoop ecosystem as well.

I know that this is an ambition I share with Brian Thomason (iamfuzz) and a number of Debian developers have offered support so I look forward to working in this area in the future.

Java 7

It was a long time coming but its finally here; to new to make the 'default-*' yet but it something I intend to work on over the next couple of releases.

Starting with a rebuild test...

and followed but a large number of bugs in Ubuntu/Debian and upstream I suspect. This transition will be important as OpenJDK7 is much more closely aligned to Oracle Java 7 (99% the same) than OpenJDK6 so has the potential to re-unite the Java world.

Testing Automation

I said this when I applied for Server Package Set upload permissions:

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 https://blueprints.launchpad.net/ubuntu/+spec/server-o-complex-deployment-testing for some of my ideas.

Ensemble is maturing and I think this is the way to go for complex deployment testing; I have started work in this area using ensemble itself to orchestrate the testing once a deployment is up an running - still WIP but hopefully both ensemble and my testing formula will mature for the next LTS.

What I like least in Ubuntu

I said this when I applied for Server Package Set permissions:

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.

I think this still holds true; I have been working as much as possible in Debian and I ran a UDW session on packaging Java libraries with Maven to help publicise the toolset in this area. Still more work (as ever) to be done.

The other area I find frustrating was the amount of time it took to get NEW packages reviewed when the Jenkins package set was landing in Ubuntu; I understand that none of the archive admins are 'full-time' so maybe it just needs more people doing it - I would be happy to help out as I believe I have the right mindset to become an archive-admin.


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.

Daniel Holbach (dholbach)

General feedback

I have sponsored a number of James' uploads and I was very happy with the amount of detail he paid attention to. He is constantly in touch with upstreams and has a great overview of the Java world. I definitely would trust him all kinds of upload rights to Ubuntu.

Specific Experiences of working together

Areas of Improvement

It'd be great to have more people involved in the Java world. I'm happy that James mentions this in his application as well and I'm glad he was always willing to run a session about Java packaging when I asked him.

Keep up the great work!

Chuck Short

General feedback

What can I say he is James Page!

Specific Experiences of working together

I have uploaded numerous packages for James since I have started working with him on the Server Team and when I need him to fix something in his work, he has never gotten upset about it.

Areas of Improvement

Just to slow down a bit, and keep track of the number of beers he owes me.

Dave Walker

General feedback

I've worked closely with James Page for over a year, communicating on a daily basis. James has a real talent for distro development, the speed that he has picked up some of the complex aspects has been truly impressive. He is becoming quite well known in the development community, due to the breadth of his work.

I've sponsored a number of James's uploads, and they have always been of a really good standard. If I do make a comment, it's usually personal preference and James always reacts well to criticism. He learns from his mistakes, and is not afraid to ask for support when unsure.

I would trust James with core-dev privileges based on a really good track record. Thanks.

Dustin Kirkland

General feedback

James is already a Core Dev and a MOTU, in my mind. I've examined dozens of his Java packages for the NEW queue, when I've been wearing my ArchiveAdministration hat. I have hardly found a single thing wrong with any of James' NEW packages. Some of them have even been large, and non-trivial, and most have been Java. We have a deft of core Java packaging skills in the Ubuntu packaging community. James adds so much to this that we should be welcoming him with open arms in the Ubuntu uploading community! Huge, huge, no-strings-attached +1!

Areas of Improvement

Carry on expanding interests into areas outside your usual areas.

Jamie Strandboge

General feedback

My interactions with James have always been positive and primarily around reviewing NEW packages of his as an archive admin. The quality of his work is very high and when feedback is given, he learns from it. I do a lot of NEW review as an archive admin and the quality of his work is so consistently high that I find myself giving a sigh of relief when I see his name in the changelog. While I have really only seen his work on Java packaging, I trust his work and it is obvious to me that he should be a core-dev.

Specific Experiences of working together

I think I ended up reviewing nearly all of James' jenkins work. This was a lot of review for me and obviously a lot of work for him but I was always very impressed by his attention to detail. I've seldom had to reject any of James' uploads, but the two times I recall were python-jenkins (orig.tar.gz checksum mismatch with upstream) and jenkins-commons-jelly (couple of missed files in debian/copyright) which were fixed promptly without complaint. He didn't make the same mistake again.

Areas of Improvement

None I can think of. Thanks James!

-- jdstrand 2011-09-16 21:09:38

Matthias Klose

General feedback

I would be happy not to sponsor James packages anymore Wink ;-) The uploads, both new packages and fixes, look fine. He participates in tasks like cleaning up NBS and fixing build failures, as well as in preparing the OpenJDK 6 -> 7 transition.

Areas of Improvement

Stop nagging me about feedback for this application ;-P


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


CategoryMOTUApplication CategoryPerPackageUploaderApplication CategoryCoreDevApplication

JamesPage/CoreDevApplication (last edited 2011-09-19 13:37:28 by davewalker)