I, Miriam España Acebal, apply for upload rights for Ubuntu Core Developer.

I am applying because I would like:

• to contribute to Ubuntu more efficiently by reducing the burden on my sponsors and, therefore, eliminating delays in getting my work sponsored.
• to be able to help beyond the server set
• to mentor new packagers-to-be (in the different programs i.e, patch pilot/whatever)

Who I am

I'm a Distro Software Engineer (a.k.a. packaging staff) at Canonical Public Cloud Team (a.k.a. CPC), but when I joined Canonical three years ago, I started at the Server Team. I am attached to the Azure Cloud, so I'm on the front line of dealing with packaging work that involves Microsoft software, like .NET or the WALinuxAgent, but not exclusively.

In my successful and previous application for Server Set package rights you can see who I am from a career point of view. Now, I can give you an insight about what I like to do (WIP).

My Ubuntu story

This time, in going to tell you how I feel being part of Ubuntu, since I already told the story of how I got here (WIP).

My involvement

These are all my sponsored uploads by other Ubuntu/Canonical members:

Graphically, here you can see in which processes I have been involved:

Examples of my work / Things I'm proud of

I'm proud of being able to upload some packages by myself since I'm a Server-dev (List to be included).

To be honest, and although it could seem strange, I'm proud of my first +1 Maintenance shift on my own after shadowing Athos Ribeiro and Simon Chopin (Thank you!). It was a significant milestone because I feel I was able to contribute even more to the Ubuntu project.

The same applies to the Ubuntu Patch Piloting initiative, in which I shadow Christian Ehrhardt on 7/10/23 and Paride Legovini and I expect to be able to do my first shift sooner.

This takes me back to when I was able to help with some FTBFS in #ubuntu-devel irc, i.e., when adapting to the new GCC14 in the context of an all-hands effort, including forwarding fixings to Debian.

Speaking about Debian and regarding to the different upstream sources we have, I don’t want to forget my involvement with upstream/debian developers when something that I’m working on could benefit them or if I have questions or issues. Some examples are:

• - with WALinuxAgent developers: https://github.com/Azure/WALinuxAgent/pull/3149

  - with mail-dmarc : https://github.com/msimerson/mail-dmarc/pull/217

  - with form: https://github.com/vermaseren/form/pull/549

  - with fftw: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074955

  - with libmail-dmarc-perl: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058492

  - with sphinx: https://salsa.debian.org/python-team/packages/sphinx/-/merge_requests/5

I also did reviews. My latest ones are:

• - samba merge from Debian in Oracular, proposed by Andreas Hasenack.

  - squid merge from Debian in Oracular, proposed by Renan Rodrigo Barbosa.

Speaking purely about uploads, from the Ubuntu Sponsorship Miner, I got them here divided in specific processes:

• BUG:

• COMPONENT-MISMATCHED:

• FTBFS:

• NEW:

• MERGE:

• MIR:

• MRE:

• SRU:

• UPGRADE:

Areas of work

* WALinuxAgent: This is one of the main packages of the Azure cloud. Last cycle, I was nominated as the Ubuntu maintainer of this package that we take directly from upstream. I recently finished the upgrade in Oracular, and the package is almost ready to land for the LTSs. For the ESM versions I'm recovering the autopkgtests and I'm training a teammate to avoid being myself a bottleneck in case of Out-of-office situations.

* DPDK MREs: I belong to the CPC team, Azure cloud, but I'm a kind of "cloud friend" for the Server Team, which participates in practically all the normal aspects of a distro-server engineer (triage, bug fixing, +1 Maintenance, ...). If I have to say a specialization there, in the past three cycles, I've been doing the dpdk packages MRE for the stable releases.

* libmail-dmarc-perl: Also on behalf of the Server Team, I drove this Main Inclusion Request that initially needed more than forty packages to be pushed through the process. Digging deeper into it and the needs of the package that used it as a dependency (spamassassin), I was able to restrict them to six, doing changes also in implementations that I forwarded to Debian and the upstream's project.

* dotnet packages: Packaging dotnet6 and dotnet7 in Ubuntu as New packages not existent on Debian was my main task for a while, for which Foundations Team supported me. I was involved with upstream (as official distro maintainer at Canonical), but I finished the hand-off to the new .NET team under the Toolchain Squad on Foundations Team last year.

* Mentoring/training: I'm already mentoring one of my squad fellows on packaging WALinuxAgent. I did mentoring before for the actual .NET squad in the hands-off and formers CPC colleagues. I did some tech talk sessions about packaging and distro cycle within my team:

• - From software to package: the origin source tarball and your friend debmake

  - Ubuntu processes involved in packaging and how-to get uploads rights

  - and outside my team, at Open South Code 2024, with the talk I submitted a bug to Ubuntu, what else? that can be seen here

Things I could do better

• Timeboxing: It doesn't get better when you have more tasks because you can do more things with your new rights, but I think it is a mixture of experience and pressure.

• Detect when a fix might be on the Ubuntu infra side or it can be detected in the release process: All the machinery behind the upload and release of a package is difficult to track for a newbie without clear indications or a point to find them. I usually read the ubuntu-devel or ubuntu-devel-discuss lists for things like this (i.e, about Britney update_output.txt for analyzing migrations )or dig into the irc logs on #ubuntu-release or #ubuntu-devel (i.e., I found there the distro checks by series and the task that it runs).

• Be more direct in asking for the needs I have to progress on my tasks.
• Don't forget the DEP-3 header on a patch!

Plans for the future

I think CPC lacks a tradition in packaging, and I would like to find a way to integrate this within the team, the people, so that whoever should or wants to can be trained in packaging as well and with the same opportunities as they would in Server/Foundations (I know these are big words).

General

The main idea of me having upload rights is to make CPC a more consistent team on the Distro side, being able to be a direct contact inside the team for complex questions or requests that need advice or acknowledgement from the ubuntu-devel community and directly helping with the usual tasks of a packager-dev person: reviewing, changing, creating, uploading and sponsoring packages.

I'm already helping others in my team with packaging advice or pre-reviews for MPs, and I also got a ping from outside the team for sponsoring openssh because I was (at that moment) the latest one that upgraded the package: these are examples of me not being able to help enough because I cannot sponsor packages.

But, my overall goal is not only to be useful in CPC but also within the Ubuntu developer community: We have a lot of bottlenecks in our distro-processes related to packaging because we are short of human resources and I would like to pitch in when the time comes (+1, Patch Pilot, and all in that I could help as a distro engineering).

What I like least in Ubuntu

I remain unhappy with the knowledge gaps or scattered documentation we have on the path/workflow to being a (PP/Set/MOTU/core)-dev. I know we have initiatives in place (Uploader Reunite/Patch Pilot/...) and I am grateful for that and for the current and past efforts made to bring this all together under one place/source but, for the future, I would like the next generations of uploaders to be able to have answers to the following questions/points as they begin their path to whatever upload-dev they choose to pursue.

* “When you seem ready, is the moment to apply for core-dev or whatever upload-right you’re pursuing…” What is the definition/measurement of “ready”? What is the minimum?

* Actual measurement of “ready”:

• - Endorsements in the application - The feelings of the other members concerning the candidate's work. - The candidate's interview in the irc meeting (but this is a post-measurement of ready for the candidate)

* Wish to have:

• - Could we identify the particular knowledge they should have, as a basis?
  • - Debian Policy from A-Z ? (This seems top high bar) - What is considered a basic and sufficient level of packaging knowledge? - How many different cases should the candidate demonstrate knowledge of, in terms of special/corner cases Does it depends on the team he/she works within?
  - They have to know the Ubuntu processes… are all of them available to the public knowledge?
  • - What happens after a package’s upload is not documented - E.g. The Update_excuses page shows packages that need attention, but where is this noted?

    • - It’s part of the description of +1MaintenanceTeam (some of the links there are very obsoletes), which could lead to confusion because that stands for a Team, and +1Maintenance, as talked about, is used day-a-day to refer to the +1 shift.

    - It’s an example of master-padawan knowledge (or onboarding concepts depending of the team)
  - Could we identify the (fast) way they have to handle a particular case?
  • - Should it include their work-setup/tooling?
    • - Should it be aligned with the existing core-dev community? If not, what are the minimums to interact with other core-devs?

  - From the last, could we identify a pair package-task <-> workflow?

  • - I made this checklist in 2022 when looking an answer to that.

  - Could we get a compendium of tools that a packager needs (installations, tips, …) ?
  • - It leads others to know tools that can help on his/her day-to-day basis.

This should be broadly speaking, independent of the mentor you have or the team you belong to—as, in my opinion, this influences a lot how difficult it is for the candidate/learner to find this information. I feel this issue is mainly due to the lack of time we have, the fast-paced environment and the nature of Ubuntu itself, but it would be worth trying to improve it.

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.

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 ===