Ubuntu Wiki

About Me

Currently, a sustaining engineer for Canonical, Ltd. We maintain current releases of Ubuntu with a heavier focus on LTS releases. A lot of my work tends to go on in the background with fixing bugs, getting new features in, and overall providing a helping hand to the engineering team. It is my goal to be one of the go-to guys when it comes to customer satisfaction with our current supported products. I deal mostly with the engineers in the userspace realm and occasionally dabble in kernel space.

Finally, throughout my journey in the opensource community, handling the balance of both community and paying customers I have been lucky enough to experience both ends of the spectrum and everything in between. From my experience I’ve accomplished roles from frontline support calls, customer on-site visits, sustaining engineering, and engineering.

I am intimately familiar with processes from both Red Hat and Canonical. I’ve been fortunate enough to have had my contributions utilized in the progression of an idea to product launch. My understanding of procedures for customer satisfaction, setting expectations, and providing insightful education to my peers are excellent and increasing every day.

I am a firm believer in getting what you paid for and the value of customer relationship. Every day I strive to exceed excellence and always on the lookout for productive ways to solve problems quicker in order to provide the highest customer satisfaction.

Contact Information

Contributions

A list of package maintenance I’ve been involved in: https://launchpad.net/~adam-stokes/+uploaded-packages

Before Canonical, I worked for 7 years at Red Hat, Inc. where I started from the bottom of the totem pole and finally ended my stay with them in their Engineering R&D for Virtualization technologies. My last project with them was Matahari, which was basically systems management and monitoring for the cloud.

https://github.com/matahari/matahari

I also wrote CAS (core analysis system) which provided support engineers with an automated way to take a kernel core dump and have a system provisioned and setup for the engineering team to analyze.

https://fedorahosted.org/cas

I was also a maintainer and still heavily involved with sosreport. Which is basically a system’s data collector for helping engineers get a peek at a clients system in order to help further troubleshoot or reproduce an issue.

https://github.com/sosreport/sosreport

Since working with Canonical I’ve done a lot of Debian/Ubuntu specific work for sosreport in order to have proper packaging and make sosreport’s gathering routines applicable on those distributions. I am also the Debian maintainer for that package as well.

Since I previously applied SOSreport is now available in Debian testing, Ubuntu main archive, and seeded on any newly released isos including Trusty.

Future Goals

My future goals are to see sustaining engineering recognized and established point of reference with regard to sustaining the foundation of Ubuntu. Eventually, I would like to make my way into a full fledged engineering role within the Foundations team.

Testimonials

This is a testimonial from www.linkedin.com/in/jkwest

Adam has always been a bit of inspiration to me on being the ideal hacker who figures it out and makes it work no matter what. He's driven and dedicated. Anyone who has him on their team, is privileged. Adam is an open-source giant.

MarkRussell

Adam has been a bug fixing force since joining Canonical. Though he's been highly productive, he also insists on quality (correct) fixes, properly following Ubuntu processes and policies, and when appropriate, always looks to push the changes upstream for everyone's benefit.

Although SEG focuses on customer-raised bugs, Adam makes sure that there is a public bug filed to match the private one and responds to comments from public side as well.

Lastly, I personally appreciate how well Adam works with his counterparts in Ubuntu Engineering, especially the Foundations team. It helps bring attention to our bugs to the right UE maintainers, which means both a faster fix *and* a more correct fix.

The SEG team has been invaluable as that link between Support and Engineering. I think they've made life much easier for both sides. Adam has been an absolutely huge part of that.

I'd also like to highlight the work he's done helping to multi-arch numerous libraries to help support our customers (and countless people around the world that need to use a certain proprietary 32-bit-only email client and want to do it on Ubuntu)! During that process it was clear that we weren't going to rush changes that would perhaps work for the use case in question but weren't correct and could cause unexpected problems for others.

Obviously I'm not the best judge of who should get core dev status, but I know that it has a lot to do with trust. Trust in tech chops is important (and required) but that's hardly enough. It seems just as important that there is trust that this person will do right by the distribution and its community. Adam sits between us support folks and Engineering, which is not an easy spot; we're always desperate to get customers off our backs first and foremost (can you blame us?). Adam is the guy patiently explaining to us that we need to follow these policies and do things correctly, because there are damn good reasons these policies exist and we're all better off that they do.

In other words, if anyone is worried that granting this status to Adam means Support is suddenly going to have carte blanche to push whatever will quiet our customers the fastest, don't. I only wish! (mostly kidding!)

SteveLangasek

Adam has been a pleasure to work with on Ubuntu over the past year. He's been a quick study, being shoved into the deep end of packaging with multiarch-enablement SRUs for precise and learning to swim. I am confident that Adam will be a good addition to core-dev - it's time for him to be sponsoring others' multiarch uploads instead of looking for sponsorship of his own.

ChristopherArges

Adam has patience and insight that make him a great person to be fixing tough bugs. He also has shown with a few special bugs (autofs/multiarch) how to determine the right fix instead of the easiest fix. Since I'm subscribed to many of his bugs, I see how well he articulates the problems and the SRU justifications. stokachu++

StéphaneGraber

I've been working quite a bit with Adam while preparing Ubuntu 12.04.1. During that time I've been sponsoring numerous multiarch enablement backports to the stable release. They all looked good and were thoroughly tested (rdepends rebuild test). Outside of 12.04.1, I've also been sponsoring changes, mostly SRUs for issues affecting large scale deployments on pretty core packages. I can't remember ever seeing but minor issues with the debdiffs he gave me. As most of Adam's work is targeted to core packages in the stable releases, I think coredev is the right next step for him. He may be misisng some of the usual dev release kind of experience we're used to, but I know he'll learn quickly and will ask others before acting.