Who I am
My name is James Falcon. I’m a software engineer at Canonical and have been working with Python for the past 10 years. Prior to working on cloud-init, I have written software professionally for avionics, telecommunications, and distributed databases. I have also made meaningful contributions to a number of open source projects.
How I came to work on cloud-init
I came to work on cloud-init through employment at Canonical. I have been working on cloud-init for the past 6 months.
Examples of my work / Things I’m proud of
My list of commits can be seen here:
Since starting on the project, I have contributed 16 commits and performed 64 reviews (as of Nov 10).
Some PRs that stand out include:
My first “real” PR which addressed and launched discussions around failing silently and feature flags.
Supporting Oracle’s IMDSv2 API
The initial implementation of the integration testing framework
The 20.3 release. The commit itself isn’t all that noteworthy, but I shepherded this release and corresponding SRU through the release process.
I also presented the integration testing framework at the 2020 cloud-init summit.
Areas of work
My two main areas of focus thus far have been Oracle IMDSv2 and integration testing. I have worked primarily alongside the cloud-init core committers on these efforts.
Things I could do better
There is still much of the cloud-init codebase that I haven’t yet had the opportunity to work with. I will learn more as I go, but in the mean time I know to ask for help when I need it. Additionally, I would like to be more involved in the #cloud-init freenode channel, though I often feel the other participants there are still better able to answer questions.
Plans for the future
I plan on continuing to learn and contribute to cloud-init. I would like to make additional progress in adding integration tests in addition to contributing to anything else on the broader project roadmap.
What I like least in cloud-init
It takes a lot of time to SRU and manually verify a release. Hopefully the integration testing goes a long way towards solving that. I also dislike the number of bash scripts and bash calls that the project relies on. That’s something that could change over the long term, though I also generally prefer not to port working code.
Endorsements (1-3 endorsements required)
As a sponsor, just copy the template below, fill it out and post it as a reply to the applicants application thread.
Please fill us in on your shared experience. Notable pull requests, improvements to the project, documentation, or special expertise brought to bear
Specific Experiences of working together
Please add good examples of your work together, but also cases that could have handled better.
Areas of Improvement
Please note specific areas that the application can continue to improve and watch out for going forward
What reviewers are looking for
- a continued history of work (6 months?)
- breadth of codebase
- breadth of types of work
- tests and their quality in both functional and unit test types
- QA, release assistance
- reviews of PRs, not their own and not only in their special focus of the codebase
- Endorsements from the Ubuntu process
- 1-3 endorsements in your application from existing committers
- demonstrates an understanding of limits of knowledge and shows a reach out to others when appropriate.