I, Cody A.W. Somerville, apply for core-dev.

Who I am

My Name is Cody Somerville. I'm from Fredericton, New Brunswick, Canada. My day job is being the release engineer for Canonical's OEM Solutions Group and at night I hack away at Xubuntu as the project lead.

My Ubuntu story

I've been involved in Ubuntu for a number of years now. Initially, my efforts were focused on community development, documentation, and marketing. In winter 2008, I was both elected as the Xubuntu Project Lead and successfully applied to become a MOTU. Since then, I have been working on a combination of technical and community challenges.

My involvement

• Xubuntu Project Lead
• MOTU
• Universe SRU Team

For more comprehensive coverage of my technical and non-technical involvement in Ubuntu, see my wiki homepage.

Examples of my work / Things I'm proud of

• dbus-launch hangs at session start waiting on socket output in libxcb (lp: #232364): With assistance from the X Team, I was able to identify that an architectural issue in libxcb caused Xubuntu (and in some cases Ubuntu) desktops to intermittently freeze on start due to a race condition. Knowing very little about the components I was working with at the time, I was able to correctly resolve the issue thanks to my personal resourcefulness, ability to rapidly learn about new topics, and my strong working relationship with my peers.

• update-grub ignores non-xen kernels if the system is a domU (lp: #291256): I noticed that update-grub ignored non-xen kernels if the system was a domU - an undesired behaviour if you're attempting to build images for non domU systems. After researching the history of the changes that introduced this behaviour, I prepared a patch which was accepted. This is another example of my ability to rapidly learn about a new software system and produce a well-rounded technical solution via consultation with domain experts and personal resourcefulness.

• dput: dput is an important tool as it allows us to easily upload our updates to packages to the repository. This is why I added several new features to dput as well as fixed several outstanding bugs. Primarily, I added the ability to pass an argument to a host configuration (ie. no longer create a new configuration stanza for each ppa you want to upload to, just type: dput ppa:<launchpad-id> <changesfile>) as well as added support for the sftp transport.

• notification-daemon using 237MB of memory (lp: #67129): While at UDS Prague, I noticed that notification-daemon was leaking memory - and it seems other people had noticed too. I used memory profiling tools to help track down a number of memory leaks and supplied a patch to the Maintainer, Michael Vogt, who accepted it and also used it in an Hardy SRU.

• amsn: I'm a big fan of providing a well rounded experience to our users. This is why I've adopted certain popular packages such as amsn in previous release cycles to help further that goal. For example, in my amsn 0.97+final-0ubuntu4 upload during the Hardy release cycle, I was able to close five bugs which consequentially helped do just that. I still keep an eye on amsn bugs to this date and answer the odd question drive-by contributors to the package shoot my way.

• Xubuntu & Xubuntu Strategy Document: I wrote the Xubuntu Strategy Document; a document which details Xubuntu's core goals, core community structure, and core set of processes. I believe this is a good example of my leadership skills and in particular my ability to clearly articulate a vision and direction. Since becoming the project lead, I've been able to grow the Xubuntu community and establish a solid cadre of contributors with clear, easy to understand delegation that results in the production of a high calibre derivative of Ubuntu with minimal "manpower" every six months.

Areas of work

• Xubuntu packages
• Liaison work with other Ubuntu development teams such as the Ubuntu Desktop Team
• Misc. work in universe

Things I could do better

One area I'd like to improve is the packaging of libraries from scratch.

Plans for the future

General

I plan to continue my involvement with Xubuntu but I'm also interested in branching out and exploring new areas. In particular, I've always had a desire to get more involved with the Ubuntu Server team to help develop an innovative server distribution with a particular focus on enterprise deployment.

Furthermore, almost none of the engineers in my team at Canonical are Ubuntu developers. I'd like to be able to further assist them in the process of becoming one though by being able to help sponsor all the great bug fixes and enhancements that are being developed for packages residing in Main for our OEM customers. I've currently made myself available to sponsor fixes to packages in universe/multiverse and have facilitated the development of connections between counterparts in the OEM Services team and the distribution team on numerous occasions already. We're already seeing some of the great work being done in the OEM Services Team make its way into Jaunty but it isn't happening fast enough. As a core developer, I could happily help expedite this.

Finally, I'd also like to help enable Ubuntu Developers (MOTU and Core Developers) by investing personal efforts into tackling both low and higher hanging fruit in our tool set. Not only will this include further improvements to standalone tools such as dput, but also the launchpad platform.

What I like least in Ubuntu

One thing I'd like to improve in Ubuntu is the Stable Release Updates process. The #1 complaint that I receive from bother home and corporate users is the number of updates that come down the pipe to a stable release and the breakage that often occurs.

I believe we can tackle this problem from a number of angles. However, one issue in particular that I'd like to highlight is that the current SRU policy suggests one shoe fits all. I don't believe this is the case. Some fixes are obvious, have little risk, and provide huge benefit but get caught up in all the paperwork. Other fixes aren't so clear and then with domain specific fixes (such as to X) there are special considerations. Instead of a one shoe fits all policy of how SRUs are suppose to work, we should have a more comprehensive policy that recognizes stable release updates aren't about making a small group of users happy, isn't about closing a bug on launchpad, nor is it about fixing that actual bug! Instead, its all about maintaining the integrity of the Ubuntu product as a whole. This is why I believe a matrix system that allows us to score a SRU candidate and easily identify special considerations such as the need for extra testing and ensure it happens could be hugely beneficial.

Furthermore, it would be nice if launchpad understood more about our processes and workflows. Although a bug report works okay for an SRU request, I find I often have to ask the requesters to provide more information or edit how they presented the information they've already entered so that other stakeholders don't get slowed down. It would be nice if launchpad was extendible in the sense that we were able to actually have SRU objects within launchpad that properly showed the relationship between the different bugs, the packages in the archive, the different stakeholders, SRU process information and state, etc.

Anyhow, I could rant on about different theories and ideas for pages.

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

Steve Magoun

• As Cody's manager at Canonical, I have the opportunity to work with him daily. Cody has excellent technical skills and the quality of his work (especially code and documentation) is consistently high. As the build/release engineer for our group, he has developed a good understanding of the challenges surrounding archive management. Cody very clearly works hard at self-improvement and always welcomes feedback from his peers. I think he would be an excellent addition to the core-dev team. Full disclosure: My group would directly benefit from Cody's membership in core-dev, though that is not why I am commenting here. I think Cody's skills, his work in the community and his consistent dedication to Ubuntu and Xubuntu stand on their own. @SteveMagoun@

Endorsements

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

MichaelVogt

General feedback

Cody analyzed and fixed some memory leak problems in the notification-daemon code. The patches he send were good and his work very valuable. I trust Cody that he has the required skills to be core-dev.

Jamie Strandboge

General feedback

I sponsored several of Cody's dput uploads. The quality of the packaging was very high, and the patches were good overall. When a bug came in on one of the patches he added, Cody was very responsive to fix it and get it reviewed for upload. I am happy to recommend Cody for core-dev, and am a little surprised he isn't one already.

Specific Experiences of working together

In addition to the dput uploads, I also worked with Cody during the 'November Nexus', which was a week long event where I and a bunch of others worked with the OEM team in Lexington. I was consistently impressed with Cody's technical skills and his ideas regarding archive organization for the OEM team.

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

CategoryCoreDevApplication