Chad Smith (chad.smith)
I, Chad Smith, apply for Per-Package Upload rights for packages <<curtin>> and <<cloud-init>>.
Who I am
Pacific Standard (UTC-0800) or Daylight (UTC-0700) Time
blackboxsw on freenode & OFTC
I am Chad Smith, a developer on Canonical's Ubuntu ServerTeam. My objective is to make complex software solutions like landscape, cloud-init and curtin more extensible, better tested, documented and easier to use.
I have a BS in Electrical Engineering and Computer Science from University of California Davis. I spent a couple of years dabbling in neural networks products
My Ubuntu story
My first exposure to Linux was Slackware '97 on embedded systems. Ubuntu changed my world view by making install and configuration of Linux on my desktop simple, usable and beautiful. I felt Ubuntu made Linux accessible to the masses. I made a permanent shift at home and work in 2004 with Warty Warthog and I haven't looked back since.
Before joining the Landscape team @ Canonical in 2011, I spent 10 years at HP, in the Open source and Linux Organization where I was a core developer writing SNMP and WBEM solutions for remote systems management. In the last couple years at HP, I developed configuration management solutions for bare-metal provisioning, monitoring and tracking the ubuntu infrastructure on which HP Cloud was running. My focus has been on remote system management and configuration for the extent of my career. Systems management should be simple, scalable and failure tolerant, it is my goal to contribute in any area which can make administration of complex systems easier.
Bugs Work and Meetings
- 6 years as developer on landscape and landscape-client
- Squad lead on one of the 3 landscape development squads for ~3 years, helped to organize and priroritize team feature work
- Nearly 1 year of development on cloud-init and curtin
- Significant bug management in maas, juju, juju charms, and lanscape related packages
- Development with a focus on improved documentation, testable and maintainable code
Setup a blog to track the bi-weekly cloud-init community status meeting cloud-init.github.io and rotate as meeting chair.
- Designed initial json-schema validation for parsing and annotating errors in #cloud-config files.
- Adding a number of subcommands to cloud-init commandline to improve issue triage of cloud-init
- collect-logs: apport integration for filing cloud-init bugs
- status: report brief status of the overall state of the cloud-init process
analyze: integrate RyanHarper's cloud-init analyze tool
- Primary driver for recent SRUs and SRU verfication for the cloud-init project
Help facilitate cloud-init and curtin transparency in the comminuty through agile tracking on cloud-init/curtrin's trello board
I'm proud of my involvement in the package release process for cloud-init. My uploads
I'm getting good use out of my package sponsorship script which replaces some of the features of Debian's retired Alioth sponshorship app.
To further document in-progress SRU validation, I've contributed to SRU tracking for each SRU such as ubuntu-SRU 2017-10-06
Cloud-init's install base is very broad as it support most major clouds. SRU testing is complex and integration testing is costly for SRU verification. As such, I've taken up writing simple tools to [[https://github.com/cloud-init/qa-scripts/blob/master/scripts/launch-ec2|launch cloud-init on
Things I could do better
I like to make our projects as transparent as possible. My intent is to improve accountability and transparency for the significant work we are performing in cloud-init and curtin projects. I expect to spend time improving our feature tracking via [Cloud-init/Curtin daily trello board](https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin).
- Extend #cloud-config schema validation for cloud-init as it is the most frequent source of user error affecting the community
- Improve response times on cloud-init and curtin bug management
- Generalize cloud-init's datasources to simplify adoption by other clouds currently unsupported by cloud-init
- Improve cloud-init and curtin documentation to lower the barrier to entry for new users
- Continue to blog about discoveries or developer pain points to get the word out about new cloud-init and curtin features
- Get curtin and cloud-init unit test coverage up to avoid regressions in behavior as we extend features.
- Help community members in #cloud-init and #curtin to best use the tools available to them
If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.
As a sponsor, just copy the template below, fill it out and add it to this section.
Chad and I have worked together for a year or so. Chad works with me on my team at Canonical on upstream and Ubuntu development of cloud-init and curtin. Chad has full commit acccess to both of these projects. I'm happy to have him as a developer in both projects and trust his judgement and development skills.
Chad has 2 very valuable passions that I've noted:
These are both great things to add to upstream and Ubuntu development.
I have no hesitation recommending chad for PPU of cloud-init or curtin.
Specific Experiences of working together
Chad and works upstream with cloud-init and curtin. In the past 3 months or so, he has done merge proposals for new ubuntu releases of cloud-init, and I have sponsored thos. He's improved the tools that we use in this area, and has done a great job.
== <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.'' ## Full list of sponsored packages can be generated here: ## http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi? === Areas of Improvement ===