I, Myles Penner, apply for PPU rights for package-set OpenStack.
Contact Information:
-
Name: Myles Penner
-
Launchpad Page: https://launchpad.net/~mylesjp
-
Matrix username: @mylesjp:matrix.org
I am applying because:
-
I’d like to eliminate delays in getting my work sponsored.
-
I’d like to reduce the burden on my sponsors.
-
I’d like to be able to sponsor work of others
Who I am
My name is Myles Penner, and I am based in British Columbia, Canada. I have been an Ubuntu user since Bionic Beaver, largely for scientific computing with the Python data science stack and software like MATLAB. I recently made a career change to computer science after a decade of mechanical engineering work in the municipal and aerospace industries and have been thrilled to contribute back to the platform I’ve been using for so long. I have been with Canonical for a little over two years with the OpenStack team largely working on OpenStack packaging, Sunbeam, and the Main Inclusion Review team.
My Ubuntu story
Examples of my work
-
OpenStack packages typically have multiple development releases per cycle, enabling me to have worked on every package in the OpenStack several times per cycle, for several cycles. This totals hundreds of OpenStack and OpenStack-adjacent package merge proposals. The type of work done on packages can include, but is not limited to:
- Creating patches to resolve issues such as Python incompatibilities or other Ubuntu-specific hangups
- python-proliantutils - patch creation for Python 3.14 behaviour change
- swift - flaky unit test fix that seems specific to LP infrastructure
- manila - upstream bug related to notifications accumulating due to not being reset between unit tests - this has since been fixed upstream
- Managing dependencies in d/control to enable/disable build or runtime dependencies
- ceilometer - drop an unnecessary dependency
- Modifying install scripts and upstream architectural changes
- octavia - re-introduce WSGI entrypoint until Ubuntu is ready to migrate to uWSGI as per upstream recommendation. This type of patch was needed on several packages and will be required until uWSGI can be implemented in the 2026.2 cycle.
- Updating signing keys to reflect the latest keys from upstream
- neutron - updating d/watch to pickup a .asc key file when available upstream
- Creating patches to resolve issues such as Python incompatibilities or other Ubuntu-specific hangups
-
List of sponsored packages I have worked on
-
List of packages uploaded on my behalf
-
Upstream OpenStack bug fixes - These bug fixes were all part of the 2026.1 Gazpacho cycle and are largely related to Python 3.14 behaviour changes.
-
I am a member of the Ubuntu MIR team and I have submitted and reviewed MIRs for many Ubuntu source packages. Some examples are as follows:
-
SRU
- Software-properties - This package is related to enabling new OpenStack versions in the Ubuntu Cloud Archive. This SRU adds support for the newest version of OpenStack to the cloud archive.
Areas of work
My Ubuntu work has largely been related to the OpenStack package set including handling the vast majority of the latest Flamingo and Gazpacho upstream package merges. This work involves merging the latest upstream release of an OpenStack package with the version in the Ubuntu Cloud Archive, handling patch mismatches or any other Ubuntu incompatibilities, testing the package, and proposing the package for upload to Ubuntu. A huge thanks to Nick Rosbrook for helping the OpenStack team buy sponsoring uploads and providing feedback on improving our packaging.
I am also part of the Ubuntu MIR team. This work involves attending weekly meetings where the MIRs currently in flight are assigned and discussed, as well as performing reviews of MIR submissions. This review involves following a defined template which dives deep into the source package in question; evaluating it for security concerns, package health, upstream support, and other aspects. Based on this review, the package can be accepted, forwarded to the Ubuntu Security Team for review, or rejected.
Things I could do better
Due to the large nature of the OpenStack package set and the fact that we have many different versions of packages in flight/stuck at various points, it can be difficult to keep the state of all packages organized and be aware of problems as they arise. I feel that I can do a better job of monitoring the end-end lifecycle of each package as it moves through migration. The team is currently developing tooling to have an at-a-glance dashboard for all OpenStack packages that aims to solve this problem.
I would also like to become more familiar with the way Debian does their syncs/merges in an effort to contribute back to Debian. The OpenStack team does development releases of OpenStack which means we are often ahead of Debian and waiting on client and library uploads. Rather than wait, I think it would be good open source stewardship to contribute back to Debian in an effort to lighten their workload as well. Their workflow is slightly different than ours but having a better familiarity with their process can be extremely valuable.
Plans for the future
The OpenStack package set is extremely large and the various stages of release each cycle puts a significant review burden on other Ubuntu team members. I would like to be able to process uploads myself to lighten the load on others, increase the speed of iteration for uploads and CI triggering, and to be able to process uploads from newer team members getting involved in packaging work. The OpenStack team is looking to increase its level of service with regards to point releases of supported packages which will further increase the amount of uploads required for the OpenStack package set. To streamline this process, the OpenStack team has been working on automation tooling to largely handle the merges automatically, including new development releases and point releases of older supported versions. This tooling has enabled better consistency, less human error in packaging, and more timely uploads for new upstream releases. The team hopes to further iterate on this tooling for the 2026.2 Hibiscus cycle.
What I like least in Ubuntu
My least favourite part of Ubuntu is the complexity and opacity of the machinery that runs when a package is uploaded and verified to be compliant. It is difficult to track whether an uploaded package FTBFS, fails autopkgtests, or fails due to a dependency being out of date without checking multiple webpages. The OpenStack team is working to remedy this with tooling to better automate package uploads and monitoring of Launchpad for OpenStack package issues with a cohesive interface. The OpenStack package set is extremely large with many packages being in various stages of flight at all times so a single point of reference where one can track their changes from merge request all the way to -proposed is desirable.
Endorsements and Comments
Ask your sponsors and people that closely worked with you to use the template below, and reply to your application with their packaging endorsement (sponsors) or comments (anyone including sponsors).
## Sponsoring feedback
* Please fill us in on your shared experience.
* How many packages did you sponsor? A list of sponsored packages can generated [via UDD here](https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi)
* 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 and next steps
What is the journey you see ahead of the applicant, the next steps they should take, the next things they likely have to learn and the next mountains to climb?