I, Miriam España Acebal, apply for upload rights for MOTU 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.

First of all, I like solving puzzles. Therefore, a broken piece of code is a perfect scenario, and if it's a broken package, it's marvellous. Sometimes, it takes more time than the one I have, and sometimes, I have no idea where to start, but it always makes me better: I learn more -even new programming languages- and build my confidence.

Another thing I like to do, after struggling with something new and going through various refinement loops on the way, is synthesise the process I did for the next time so that I'm able to explain it to someone who has no experience whatsoever with it. This sometimes leads me to write things (if I have the time) or share the knowledge with someone who might be interested.

I like to get to know the operating system, to know it well enough to use some tricks for things that I can't do at first.

I have to admit that I don't always have the time for the things I like (like everyone else), which makes me lose confidence in these skills, or that I can't catch up on certain things or forget others that I use less due to circumstances.

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 in my application for Server Set package rights.

I can sum it up in one word: pride. We are not perfect (nothing is), but I feel that there is always the attitude to fix and improve, driving it especially through the people, the Ubuntu community.

And with open eyes and full hearts... we can't lose.

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:

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.

  - nspr ftbfs on plucky, proposed by Lena Voytek.

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 engineer).

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 depend 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 entirely documented: The Proposed Migration is explained here and in the Ubuntu Maintainers Handbook, but what about the queues?

  • 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 also noted in the Proposed Migration wiki page... my fault for looking for update_excuses because sometimes is common to refer to this like "Did you check the update_excuses page?" and you maybe cannot realize that it is the migration process.

  • 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 for interacting with other core-devs?

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

  • I made this checklist in 2022 when looking for 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 our lack of time, 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.

Paride Legovini

General feedback

I think Miriam is ready to become MOTU right now. This is true from the technical point of view (she has enough packaging skills / experience) and from the trust and knowledge of processes point of view.

Specific Experiences of working together

I sponsored some packages for Miriam (this wiki page lists them), and when I reviewed them they were ready to be uploaded, my comments being mostly nits. I shared a "Patch Pilot" rotation with Miriam, and the collaboration was smooth and productive: we split tasks between us, worked on them independently, and then did some peer review towards the end of the shift.

Even if now sponsoring uploads, I had the opportunity to see of lot of work done by Miriam in the form of MPs and other proposed changes. What I saw was upload-grade work, and more importantly I saw how Miriam is receptive to review feedback and able to make best use of it.

Miriam also has experience with MIRs, MRE uploads, and other Ubuntu processes.

Speaking of trust: I have known Miriam for years now, she is an excellent Ubuntu member, already has PPU upload rights for Server, and will make an excellent MOTU.

Areas of Improvement

I believe that this MOTU application could relatively easily be turned into a CoreDev application by adding work on library transitions and to some other "core" components of Ubuntu, like the britney hints. I suggest working in this direction.

Bryce Harrington

General feedback

Miriam is a regular attendee at the Server Team's "Bug Housekeeping" meeting, where she's an active participant. We've been able to suggest bugs providing a variety of different kinds of challenges. Some have been quite a bit of work or have involved unusually tough challenges. She's not shy about asking for advice when she feels out of depth, and as a result her work tends to be well thought out and well tested at time of uploading.

Specific Experiences of working together

An MIR for an email-related perl module has been the biggest thing I've worked on with Miriam so far. While the module had been in main once long ago, a more rigorous approach was required this time. Unfortunately, the package in question had a number of dependencies which also needed to be handled with rigor this time as well, each needing its own detailed MIR review, each with its own sets of peculiarities needing researched and/or addressed, all of which Miriam took on and resolved. In particular, there had been a desire to evaluate an alternative Perl module for one of the dependencies, requiring her to modify perl code to adapt. I'd not worked on an MIR of this magnitude myself, and was impressed at how much dedication she put into it. While I've worked with Miriam on a number of bugs, this particular MIR experience convinces me she would be a valued addition to the MOTU team, and can be safely entrusted with MOTU upload rights.

Another specific area I'd call out is her attentiveness to documenting processes. The Ubuntu Maintainer's Handbook has many contributions from her. When she finds something not adequately documented there, she takes the initiative to add it!

Like Paride I also think she's well on her way to CoreDev, if not already there.

Areas of Improvement

Miriam has always been quite good at asking for advice on areas for self-improvement, not only with packaging but also self confidence and communication skills. Everything I've recommended she's taken on and achieved. I'm certain she'll continue to find and improve other attributes as needed.

Athos Ribeiro

General feedback

While I only sponsored a single package for Miriam (https://launchpad.net/ubuntu/+source/python-chemspipy/2.0.0-2ubuntu1), Miriam has been quite involved in the server team work for a few years now (as Bryce mentioned).

From her work, I would like to highlight her efforts on including .NET in Ubuntu, which is far from trivial and I am unsure how many non-core-devs out there would be able to lead such efforts - this would be an intensive task even for experienced core-devs.

IMHO, Miriam is ready for MOTU rights for a while now, as already pointed out by Paride and Bryce above. Moreover, this should allow Miriam to get more volume on her uploads so she can set a broader upload record to prove the DMB she is ready to be a core-dev.

Specific Experiences of working together

I did many pairing sessions, code reviews, bug triage sessions, and one or two +1 maintenance shifts together with Miriam. She is always eager to learn new processes and tools. In particular, I like the way she has been conducting her Ubuntu Server team bug triage shifts, always driving bugs closer to a conclusion.

Areas of Improvement

+1 on Paride's feedback here: working on transitions would be a final step to have a complete core-dev case for the DMB.

Graham Inggs

General feedback

I've sponsored 17 uploads for Miriam. The quality has always been good. Miriam will ask questions when things are unclear. I trust that Miriam should be a MOTU without delay.

Specific Experiences of working together

Most of the uploads I sponsored were dotnet6 and dotnet7 packages. However, the initial uploads of both of these were new packages, packaged from scratch, and had to be bootstrapped in the archive. This was a huge undertaking, but Miriam persevered. I also sponsored an SRU of freeradius (LP: #2042824), which was verified and landed in Noble.

Areas of Improvement

I can't think of any areas that need improving for this application. I would like to see work on +1 Maintenance and Patch Pilot as a MOTU, and hope to be able to endorse Miriam's CoreDev application soon!

---

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

---