I, Chris Peterson, apply for core-dev

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 more involved in the community (sponsoring, patch pilot, etc.)
• My work may require touching various packages, including those in main, for which there is no distinct package-set goal and MOTU/PPU won't cover packages in main.
• It will facilitate my general distro related work (+1 maintenance, proposed-migrations, etc.)

Who I am

Hi, my name is Chris Peterson and I am a software engineer on Canonical's Foundations team.

Prior to joining Canonical, I received my Master's in Computer Science from the University of California, Davis, where I researched semantic parsing in the areas Natural Language Processing and Computational Linguistics. Before that, I received my Bachelor's in Computer Science & Engineering from the University of Nevada, Reno, where I performed research in a Social Robotics laboratory.

I live in California, United States, and when I'm not writing software I enjoy building keyboards, playing the bass guitar, or playing video games.

My Ubuntu story

Back in my first year of college when I started to learn programming and what Linux was all about, I started with Ubuntu (Trusty). For a short time I bounced around different distributions, though mostly Ubuntu based, and eventually came back to Ubuntu after working in a robotics lab which relied on it for its software (ROS). Since then it's been my daily driver for everything I do. I am passionate about open source and working on Ubuntu everyday brings me great joy.

My involvement

Examples of my work / Things I'm proud of

• An exhaustive search of my Sponsored Uploads

• Four +1 maintenance shifts so far:

  • https://lists.ubuntu.com/archives/ubuntu-devel/2023-December/042858.html

  • https://lists.ubuntu.com/archives/ubuntu-devel/2024-February/042911.html

  • https://lists.ubuntu.com/archives/ubuntu-devel/2024-April/042958.html

  • https://lists.ubuntu.com/archives/ubuntu-devel/2024-June/043020.html

• MIR
  • python-aiohttp

    • https://bugs.launchpad.net/ubuntu/+source/python-aiohttp/+bug/2048808

    • A sort of pseudo-MIR, where I performed a comprehensive analysis of python-aiohttp, a dependency of Subiquity, and determined it's not a good candidate for MIR but still merits some serious security review. I received positive remarks for this MIR by Seth Arnold on the security team, which felt nice considering it was my first MIR

  • libsub-prototype-perl

    • https://bugs.launchpad.net/ubuntu/+source/libsub-prototype-perl/+bug/2067654

    • I began this MIR due to libsub-override-perl growing a dependency on it. However, by the time I went to post my findings on libsub-prototype-perl, libsub-override-perl had been marked for demotion to Universe. While I didn't take this MIR to completion either, I believe it still helps to demonstrate my familiarity with the process.
• seed changes

  • https://code.launchpad.net/~cpete/ubuntu-seeds/+git/ubuntu/+merge/468628

    • Remove ssh-import-id from server-minimal in jammy. See the livecd-rootfs + ubuntu-meta entry in SRUs for more details.
• SRU
  • apport

    • https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2067775

    • The listed bug outlines the SRU for updating the apport package hook for subiquity, targeting Noble and Jammy. In this effort, I also coordinated with bdrung to stage other uploads for the Noble SRU, fix issues we found in autopkgtest after upload, and verify the other SRU bugs.
  • livecd-rootfs + ubuntu-meta:

    • https://bugs.launchpad.net/subiquity/+bug/1974483

    • A complicated SRU. Jammy ubuntu-server images were getting shipped with the behavior of openssh-server always being installed invariant of user choice due to a dependency on ssh-import-id in the server-minimal seed. Because the ubuntu-server-minimal metapackage is defined by this seed, which also gets installed during image builds, this required a seed change (see above) and an ubuntu-meta SRU to update the metapackage dependencies. The final complexity here was the usage of Task headers, which can't be fixed post release, so it required some livecd-rootfs changes as well.
  • livecd-rootfs:

    • https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2077899

    • A relatively simple SRU, which required updating a hard coded model assertion in one of the ubuntu project's hooks in preparation for the 24.04.1 release.
• SRU Verification

  • https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2066995

  • https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2069360

  • https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2072751

  • https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2047314

• Merges
  • needrestart 3.6-8

    • https://bugs.launchpad.net/ubuntu/+source/needrestart/+bug/2064680

    • This was my first merge and definitely could have gone better in a few ways: TIL is not always the best person to ask about a package (read the changelog! sorry @schopin), I could have squashed all of the autopkgtest changes, and I made some rookie mistakes with the changelog formatting.
  • skimage 0.23.2-1

    • https://bugs.launchpad.net/ubuntu/+source/skimage/+bug/2068540

    • Two for the price of one: I was investigating an autopkgtest regression in skimage on s390x due to the pytest8 transition, and while we drifted a few versions out of sync with Debian it so happened the upstream fix for the regression I encountered had made it to Debian.
  • util-linux 2.40.2-1

    • https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2072813

    • A slightly non-standard merge. At the time util-linux was version 2.40.2-7 in Debian, but to avoid the login package transition introduced in 2.40.2-3, I decided to merge at an earlier version. git-ubuntu made this surprisingly easy, although in the end I needed to supply a debdiff since it seems that the git-ubuntu importer doesn't support non-tip merges.
• Syncs

  • https://bugs.launchpad.net/ubuntu/+source/privoxy/+bug/2071115

• Transitions
  • pytest 
    • I worked to move along the pytest 7 to pytest 8 transition during my June 2024 +1 maintenance shift, which is detailed in my report.
  • 64-bit time_t
    • During the time_t 32-bit to 64-bit transition I assisted in identifying relevant regressions, retrying tests/builds, hinting packages, and creating tracking bugs for related test failures
• Documentation:

  • Update the wiki on Mirrors to explicitly list how to find existing mirror information: https://wiki.ubuntu.com/Mirrors?action=info

• Subiquity:

  • Improved error handling and UX in Subiquity to inform users about avoidable errors caused by faulty autoinstall configurations.

  • I re-wrote the autoinstall validation script and made it user facing so users can prevalidate their autoinstall configurations.

  • I've been working to support MOK enrollment in Subiquity and while we're not there yet, I've worked to make this type of work testable even in the absence of relevant hardware.

  • Reduced the overall installation time significantly by modifying the final unattended-upgrades step when setting up the target system.

  • Many improvements to the bug reporting experience in Subiquity. In particular I've worked to make the manual apport bug reporting process (i.e., via ubuntu-bug or similar) more useful (LP: #2067775) and make that consistent with Subiquity's automatic crash report generation.

Areas of work

As part of Canonical's Foundations Team I spend a majority of my time working on installer related things, primarily Subiquity. While this often includes work in projects which are also not conventionally packaged, such as Curtin or Probert, it also includes work in archive packages such as livecd-rootfs, Casper, or ubuntu-meta. I expect core dev privileges will most facilitate my work by removing the need for sponsorship to make changes to these packages. However, given my experience is still limited with some of these core archive packages, I certainly still expect to ask for review and thoroughly test changes before committing something I'm not 100% certain about.

I also spend time working on Apport, fixing bugs and working to improve bug reporting in the installers. In particular, over the last two release cycles I have been collaborating within Foundations and across Desktop and Server to improve the Apport bug reporting process in general among the various installer related tools.

As part of my more general packaging related responsibilities on the Foundations team, I also participate in regular +1 maintenance and proposed-migration work.

Things I could do better

• Get more familiar with the automation/tooling that's available to better standardize my workflow.
• Increase my participation on IRC
• Improve my knowledge of Debian and their processes/tooling.

Plans for the future

General

• Continue to make contributions to Subiquity, making it more robust and improving the overall installation experience.
• I would also like to leverage my upload privileges to help sponsor work within my team, engage in patch piloting, and conduct more effective +1 shifts.

What I like least in Ubuntu

• Ubuntu development process documentation is very disjoint, which makes things difficult for newcomers. Best practices are not always clear and may also depend on who you ask. Continued work on centralized documentation, like the ubuntu-packaging-guide, is sorely needed.

• The Launchpad UI. Finding what you are looking for can be difficult if you don't know exactly where it is. Dedicated sections in the developer documentation would greatly help with this.

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

Endorsements

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

Łukasz 'sil2100' Zemczak

General feedback

Chris, even though still relatively new in the Ubuntu ecosystem, demonstrated multiple times his passion, determination and growing experience with regards to distro-work. Chris actively participated in multiple archive activities, such as helping with transitions, +1 maintenance, proposed-migration etc. Chris also is never afraid to ask for clarification or help when in doubt, which is essential when starting off as a core developer. Furthermore, Chris seeks mentorship actively, being trained by more experienced core-developers on a weekly basis. I gladly endorse Chris on his road to an official Ubuntu Core Developer. I think he's ready.

Specific Experiences of working together

I have officially sponsored only one package for Chris so far, but as his manager and co-mentor, I have insight into all the great work that Chris is performing. In my mind he demonstrated particular excellence during the infamous xzutils vulnerability and time_t crunches: when we announced an all-hands-on-deck, Chris answered. And even though he didn't yet feel 100% comfortable back then with distro-related topics, his help was invaluable. At the same time, as a main developer of subiquity, Chris by default has a lot of contact with Ubuntu per-se, making him a great candidate.

Areas of Improvement

Chris sometimes can be overly ambitious, taking on his back too much for comfort. So I would like him to be a bit more mindful of his limits.

Daniel Bungert

General feedback

Chris is a colleague on Subiquity, and my mentee as part of the Foundations team.

From Day 1 I stressed the importance of a mix of distro work as part of the Foundations experience. Someone new to working on the installer might find that surprising, but the fact is that sometimes the best place to fix an install issue is the archive, so core-dev is a useful skill. Plus, multiple core installer-related components are, and will remain, following the archive process, such as livecd-rootfs and casper.

Chris has taken that feedback seriously, incorporating a mix of various distro tasks into the narrow slice of time in the week for things not directly on the Subiquity or related codebases.

I appreciate that Chris is involving himself in Apport as of late, both something we're trying to improve within Subiquity and also land bug reporting improvements in related components.

I trust Chris to seek out code reviews and ask questions.

Please approve Chris for core-dev.

Specific Experiences of working together

I am pleased with the growth Chris has shown in core-dev type tasks. Recently he took on the challenge of landing seed changes in a SRU along with paired livecd-rootfs changes so that we could fix an issue where openssh-server was installed when it shouldn't. (LP: #1974483)

Numerous Subiquity examples could be listed here, I'm choosing one that I'm particularly happy with. As part of work on autoinstall user experience improvements, Chris saw the opportunity to make it easier to validate autoinstall outside of the installer environment - https://github.com/canonical/subiquity/pull/1901 - this was work that Chris identified and drove.

Areas of Improvement

I have no particular concerns to list here - if I did, I would be working on them with Chris during our 1:1s.

-- dbungert 2024-09-05 19:00:08

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.''
## Full list of sponsored packages can be generated here:
##  https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi
=== Areas of Improvement ===

CategoryCoreDevApplication