I, Renan Rodrigo Barbosa, apply for Ubuntu Server Developer.

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.
• Being able to upload packages for the Server team will provide me with a more solid base for a future Core Developer application, which in turn will allow me to help improving the distro as a whole, and work on guiding new developers and sharing what I learned.

• I'll have a neat rr@ubuntu.com mail address.

Who I am

I am a software engineer working on the Ubuntu Server team. In the Server team, I currently focus in helping with the PHP stack, the HA stack (and a little ruby as part of that), and the Pro Client package maintenance.

I have participated in the Brazilian qualifiers for Wordskills on Computer Networks, earning a gold medal in the regionals and a bronze medal in the national qualifiers. Unfortunately the 3rd place is not going international it seems (: But still 3rd in national level.

I have a degree in Mathematics with postgrad studies in computer networks, followed by a Master's degree in CS from the University of São Paulo, in Brazil, where I am originally from and currently based in. My research was focused on compatilibity between traditional networks and SDNs. Together with this research I worked on Kytos, a Brazilian open-source SDN platform.

I lived in Czechia working for Red Hat, where I worked on Beaker, a solution for managing and automating labs of test computers - similar in purpose to Testflinger.

I have a python background, but have also worked with web front-end applications using TS+React. After joining Canonical 4+ years ago I started having some touch with packaging. During this time I was developing the Ubuntu Pro Client.

My Ubuntu story

<< Insert the emotional story about Ubuntu being my first distribution and the excitement of getting the shipit CDrom back then >>

No srsly I have been using Debian and Ubuntu as my choices since I started Linuxing around. I got in touch with Debian (as a sysadmin) during the Worldskills competition, as the Linux servers there were all Debian. Ubuntu came later as a better option to run in my own laptop - and I kept switching between these two on occasion.

I have taught people how to use Ubuntu (and Kubuntu) on their desktops ~before it was cool~. Now in the Server team, I migrated most of my systems to Ubuntu again, now running 24.04 LTS (The exceptions are the Steam Deck and the old Windows PC catching some dust).

My involvement

Quick link to the full sponsorship list

Examples of my work / Things I'm proud of

Package Merges and Syncs

My first merges were squid for Oracular and then Plucky - I'm proud of starting to get my hands in the distro work:

* squid/6.10-1ubuntu1, submitted in MP: #472902 and sponsored by athos-ribeiro

* squid/6.13-1ubuntu1, submitted in MP: #481434 and sponsored by tsimonq2

Then I joined the Server team and started working in Questing:

* kronosnet/1.31-1ubuntu1, submitted in MP: #486320 and sponsored by ahasenack

* crmsh/4.6.1-2ubuntu1, submitted in MP: #486318 and sponsored by lvoytek

* booth/1.2-3ubuntu1, submitted in MP: #486439 and sponsored by sudip

* ruby-childprocess/4.1.0-3ubuntu1, submitted in MP: #487160 and sponsored by lvoytek

* resource-agents/1:4.16.0-3ubuntu1, submitted in MP: #487822 and sponsored by ahasenack

* corosync/3.1.9-2ubuntu1, submitted in MP: #487820 and sponsored by slyon

* pacemaker/3.0.0-2ubuntu1, submitted in MP: #486655 and sponsored by athos-ribeiro

* fence-agents/4.16.0-3ubuntu1, submitted in MP: #487821 and sponsored by lvoytek

* php8.4/8.4.8-1ubuntu1, submitted in MP: #487823 and sponsored by bryce

* thin/1.8.2+git20250216.de6b618-1ubuntu1, submitted in MP: #488105 and sponsored by ahasenack

* pcs/0.12.0.2-1ubuntu1, submitted in MP: #488136 and sponsored by ahasenack

* php8.4/8.4.11-1ubuntu1, submitted in MP: #490480 and sponsored by ahasenack

* pcs/0.12.1-2ubuntu1, submitted in MP: #490766 and sponsored by slyon

I didn't have to request more than one sync so far:

* open-vm-tools/2:13.0.0-2, request submitted in LP: #2121197 and sponsored by rikmills

And I know when not to sync ever - updated the blocklist to avoid conflicts with Debian on:

* Block docker-compose and then remove it from Questing, both reviewed and applied by paelzer

To allow the removal+block, I changed docker-compose-v2 to Provide docker-compose in

* docker-compose-v2/2.37.1+ds1-0ubuntu2, sponsored by athos-ribeiro

Bug Fixes

* LP: #2100851 fixed in shtool/2.0.8-10ubuntu1, as submitted in MP: #482968 and sponsored by athos-ribeiro

* LP: #2098515 fixed in open-iscsi/2.1.10-3ubuntu4, as submitted in MP: #484151 and sponsored by lvoytek

* LP: #2105849 and LP: #2113983 fixed in psmisc/23.7-2ubuntu1, as submitted in MP: #486045 and sponsored by seb128

* LP: #2116035 fixed in php-lorenzo-pinky/1.1.0-2ubuntu1, as submitted in MP: #490032 and sponsored by lvoytek

* LP: #2119335 and LP: #2116038 fixed in symfony/6.4.21+dfsg-2ubuntu1, as submitted in MP: #490278 and sponsored by athos-ribeiro

* LP: #2116034 fixed in php-league-html-to-markdown/5.1.1-3ubuntu1, as submitted in MP: #490434 and sponsored by bryce

* LP: #2116037 fixed in php-tijsverkoyen-css-to-inline-styles/2.3.0-2ubuntu1, as submitted in MP: #490202 and sponsored by bryce

SRUs

Most of the SRUs I have done are ubuntu-advantage-tools SRUs, for Pro Client releases. Those follow the ubuntu-advantage-tools exception - which means the upload to devel itself is bound to SRU verification rules. Although I understand the DMB would want to see more variety package wise, I was forged here: the Client made me learn a lot about the SRU process - to properly understand what the exception was about, I needed visibility of the regular process to get why we had differences, and how those apply compared to the standard. My exercise shows improvement over time (from horrible "pls uplod dis for I" to "here SRU team this is a responsible piece of work we could send to the stable releases"). See:

* LP: #1956456, uploaded to Jammy (ubuntu-advantage-tools/27.5~22.04.1), SRUed to Impish (ubuntu-advantage-tools/27.5~21.10.1), Hirsute (ubuntu-advantage-tools/27.5~21.04.1), Focal (ubuntu-advantage-tools/27.5~20.04.1), Bionic (ubuntu-advantage-tools/27.5~18.04.1), Xenial (ubuntu-advantage-tools/27.5~16.04.1), sponsored by sergiodj.

* LP: #1989279, uploaded to Kinetic (ubuntu-advantage-tools/27.11~22.10.1), SRUed to Jammy (ubuntu-advantage-tools/27.11~22.04.1), Focal (ubuntu-advantage-tools/27.11~20.04.1), Bionic (ubuntu-advantage-tools/27.11~18.04.1), Xenial (ubuntu-advantage-tools/27.11~16.04.1), sponsored by paride.

* LP: #1990907, not uploaded to Kinetic due to the Beta Freeze...(ended up being fixed in 21.11.2), but as it was a critical bugfix it got SRUed to Jammy (ubuntu-advantage-tools/27.11.1~22.04.1), Focal (ubuntu-advantage-tools/27.11.1~20.04.1), Bionic (ubuntu-advantage-tools/27.11.1~18.04.1), Xenial (ubuntu-advantage-tools/27.11.1~16.04.1), sponsored by ahasenack.

Before the ESM+Apps + Pro GA, the client was in an inconsistent state, with sequential changes based on product decisions.

* LP: #1991173, uploaded to Kinetic (ubuntu-advantage-tools/27.11.2~22.10.1), SRUed to Jammy (ubuntu-advantage-tools/27.11.2~22.04.1), Focal (ubuntu-advantage-tools/27.11.2~20.04.1), Bionic (ubuntu-advantage-tools/27.11.2~18.04.1), Xenial (ubuntu-advantage-tools/27.11.2~16.04.1), sponsored by ahasenack.

27.13 was by far the most complicated release, because of the ESM-Apps release together with APT-News. Made me learn a lot about regressions :|

* LP: #2003018, uploaded to Lunar (ubuntu-advantage-tools/27.13~23.04.1), SRUed to Kinetic (ubuntu-advantage-tools/27.13~22.10.1),Jammy (ubuntu-advantage-tools/27.13~22.04.1), Focal (ubuntu-advantage-tools/27.13~20.04.1), Bionic (ubuntu-advantage-tools/27.13~18.04.1), Xenial (ubuntu-advantage-tools/27.13~16.04.1), sponsored by ahasenack.

* LP: #2003977, uploaded to Lunar (ubuntu-advantage-tools/27.13.2~23.04.1), SRUed to Kinetic (ubuntu-advantage-tools/27.13.2~22.10.1),Jammy (ubuntu-advantage-tools/27.13.2~22.04.1), Focal (ubuntu-advantage-tools/27.13.2~20.04.1), Bionic (ubuntu-advantage-tools/27.13.2~18.04.1), Xenial (ubuntu-advantage-tools/27.13.2~16.04.1), sponsored by ahasenack.

* LP: #2006765, uploaded to Lunar (ubuntu-advantage-tools/27.13.5~23.04.1), SRUed to Kinetic (ubuntu-advantage-tools/27.13.5~22.10.1),Jammy (ubuntu-advantage-tools/27.13.5~22.04.1), Focal (ubuntu-advantage-tools/27.13.5~20.04.1), Bionic (ubuntu-advantage-tools/27.13.5~18.04.1), Xenial (ubuntu-advantage-tools/27.13.5~16.04.1), sponsored by sergiodj.

* LP: #2008814, uploaded to Lunar (ubuntu-advantage-tools/27.13.6~23.04.1), SRUed to Kinetic (ubuntu-advantage-tools/27.13.6~22.10.1),Jammy (ubuntu-advantage-tools/27.13.6~22.04.1), Focal (ubuntu-advantage-tools/27.13.6~20.04.1), Bionic (ubuntu-advantage-tools/27.13.6~18.04.1), Xenial (ubuntu-advantage-tools/27.13.6~16.04.1), sponsored by athos-ribeiro.

* LP: #2015241 and LP: #2015302, uploaded to Lunar (ubuntu-advantage-tools/27.14.4), SRUed to Kinetic (ubuntu-advantage-tools/27.14.4~22.10), Jammy (ubuntu-advantage-tools/27.14.4~22.04), Focal (ubuntu-advantage-tools/27.14.4~20.04), Bionic (ubuntu-advantage-tools/27.14.4~18.04), Xenial (ubuntu-advantage-tools/27.14.4~16.04), sponsored by athos-ribeiro.

* LP: #2038461, uploaded to Noble (ubuntu-advantage-tools/30), SRUed to Mantic (ubuntu-advantage-tools/30~23.10), Lunar (ubuntu-advantage-tools/30~23.04), Jammy (ubuntu-advantage-tools/30~22.04), Focal (ubuntu-advantage-tools/30~20.04), Bionic (ubuntu-advantage-tools/30~18.04), Xenial (ubuntu-advantage-tools/30~16.04), sponsored by bryce.

* LP: #2067319, uploaded to Oracular (ubuntu-advantage-tools/32.3), SRUed to Noble (ubuntu-advantage-tools/32.3~24.04), Mantic (ubuntu-advantage-tools/32.3~23.10), Jammy (ubuntu-advantage-tools/32.3~22.04), Focal (ubuntu-advantage-tools/32.3~20.04), Bionic (ubuntu-advantage-tools/32.3~18.04), Xenial (ubuntu-advantage-tools/32.3~16.04), sponsored by athos-ribeiro.

* LP: #2069237, uploaded to Oracular (ubuntu-advantage-tools/33), SRUed to Noble (ubuntu-advantage-tools/33~24.04), Jammy (ubuntu-advantage-tools/33~22.04), Focal (ubuntu-advantage-tools/33~20.04), Bionic (ubuntu-advantage-tools/33~18.04), Xenial (ubuntu-advantage-tools/33~16.04), sponsored by lucaskanashiro.

* LP: #2060769, uploaded to Oracular (ubuntu-advantage-tools/33.1), SRUed to Noble (ubuntu-advantage-tools/33.1~24.04), Jammy (ubuntu-advantage-tools/33.1~22.04), Focal (ubuntu-advantage-tools/33.1~20.04), Bionic (ubuntu-advantage-tools/33.1~18.04), Xenial (ubuntu-advantage-tools/33.1~16.04), sponsored by lucaskanashiro.

* LP: #2083973, uploaded to Plucky (ubuntu-advantage-tools/35), SRUed to Oracular (ubuntu-advantage-tools/35~24.10), Noble (ubuntu-advantage-tools/35~24.04), Jammy (ubuntu-advantage-tools/35~22.04), Focal (ubuntu-advantage-tools/35~20.04), Bionic (ubuntu-advantage-tools/35~18.04), Xenial (ubuntu-advantage-tools/35~16.04), sponsored by lvoytek.

* LP: #2106660, uploaded to Plucky (ubuntu-advantage-tools/35.1ubuntu0), SRUed to Oracular (ubuntu-advantage-tools/35.1ubuntu0~24.10), Noble (ubuntu-advantage-tools/35.1ubuntu0~24.04), Jammy (ubuntu-advantage-tools/35.1ubuntu0~22.04), Focal (ubuntu-advantage-tools/35.1ubuntu0~20.04), Bionic (ubuntu-advantage-tools/35.1ubuntu0~18.04), Xenial (ubuntu-advantage-tools/35.1ubuntu0~16.04), sponsored by lvoytek.

* LP: #2112382, uploaded to Questing (ubuntu-advantage-tools/36ubuntu0), SRUed to Plucky (ubuntu-advantage-tools/36ubuntu0~25.04), Oracular (ubuntu-advantage-tools/36ubuntu0~24.10), Noble (ubuntu-advantage-tools/36ubuntu0~24.04), Jammy (ubuntu-advantage-tools/36ubuntu0~22.04), Focal (ubuntu-advantage-tools/36ubuntu0~20.04), Bionic (ubuntu-advantage-tools/36ubuntu0~18.04), Xenial (ubuntu-advantage-tools/36ubuntu0~16.04), sponsored by athos-ribeiro.

PHEW

It doesn't mean I have not done other SRUs; in fact, my first ones were done when I started understanding the process - So I have driven them from fixing the bug, to preparing paperwork, to performing testing and such, but not uploading the packages for some reason.

* LP: #1955471, uploaded to Jammy (update-manager/1:22.04.5), SRUed to Focal (update-manager/1:20.04.10.10). brian-murray did the uploads after I sent the patch in the bug, I have performed the verification too. I'm not mentioned in the changelogs, unfortunately.

* LP: #1991533, uploaded to Kinetic (update-manager/1:22.10.3), SRUed to Jammy (update-manager/1:22.04.10), Focal (update-manager/1:20.04.10.11). Both uploaders, vorlon and brian-murray, mentioned me in the changelogs I have done the work here too, just didn't upload it.

* LP: #2002168, uploaded to Lunar (update-notifier/3.192.61), SRUed to Jammy (update-notifier/3.192.54.5), Focal (update-notifier/3.192.30.16), Bionic (update-notifier/3.192.1.18), Xenial (update-notifier/3.168.19). paelzer uploaded all of the versions I worked here in my behalf, but I have hit the bad luck of being superseded by the lamoura's uploads. My name is in all changelogs though, and I was responsible for driving this (paperwork, verification) with the versions that ended up being accepted.

But then, I have also SRUed my own non-u-a-t uploads in:

* LP: #2008212, uploaded to Lunar (update-notifier/3.192.63), SRUed to Jammy (update-notifier/3.192.54.6), Focal (update-notifier/3.192.30.17), Bionic (update-notifier/3.192.1.19), Xenial (update-notifier/3.168.20), sponsored by athos-ribeiro.

* LP: #2015420, uploaded to Noble (update-notifier/3.192.68) by enr0n as he dealt with some translations, but it's my change there :), SRUed to Jammy (update-notifier/3.192.54.8), Focal (update-notifier/3.192.30.19), Bionic (update-notifier/3.192.1.21), Xenial (update-notifier/3.168.22), sponsored by enr0n.

* LP: #2098515, uploaded to Questing (open-iscsi/2.1.10-3ubuntu4), SRUed to Plucky (open-iscsi/2.1.10-3ubuntu3.1), Oracular (open-iscsi/2.1.10-1ubuntu1.2),Noble (open-iscsi/2.1.9-3ubuntu5.4),sponsored by slyon.

Autopkgtest & DEP8

Although not having many package changes and bugfixes in that sense, I do understand dep8 tests, their purpose, how to add and modify them, how britney triggers reverse dependency tests on uploads, and all. In fact I have done work that involved autopkgtests:

* First and foremost, my merge proposals always come with the autopkgtest results from a ppa for that particular upload (well a few of them don't but I have described the reasons why - usually infrastructure). Although I understand sending MPs and building in PPAs is not a hard requirement for Ubuntu development, those practices are common in the Server team (which rights I happen to be applying to)

* I recently (re)triaged bugs with needs-dep8 tag on Launchpad, actually finding many entries that didn't need the tests anymore either by already having them implemented or by not being in the archive for the devel release anymore

* The psmisc bugfix listed above involved dealing with autopkgtests

* The php-related packages above (php-lorenzo-pinky symfony php-league-html-to-markdown php-tijsverkoyen-css-to-inline-styles) had tests failing after the libxml2 transition, so I was running dep8 tests for debugging and fixing these later.

MIRs

I have filed several MIR requests myself, mostly dealing with Ruby package dependencies:

* In ruby version 3.3.4, there was a decision in Debian to follow upstream recommendations on separating gems from the ruby interpreter itself, for clarity and ease of maintenance. Debian decided to stop Providing the gems which were already packaged separately, so other packages could Depend on the gems directly. Some of those separate gems became Depends of libruby itself, and others became dependencies of other packages already in main. So I had to file bugs to MIR ruby-did-you-mean, ruby-minitest, ruby-power-assert, ruby-test-unit, and ruby-csv (for libruby) and ruby-base64 (for ruby-sinatra). No alarms and no surprised in any of those, all went smooth.

* The ugly duckling in the above change was ruby-json, which needed to be MIRed as a dependency of pcs. Unlike other gems, ruby-json was already the target of a few CVEs, which called the security team's attention. Besides that, the version in Debian/Ubuntu was quite behind upstream, so an update was deemed as necessary for the promotion. This took longer but ended up in the best possible shape - no CVEs in the available versions, and I have myself a compromise (and a bug open) to update the version as soon as the archive is open for the next release.

* In the questing development cycle we were able to sort out a tricky move that was bothering us for a while: ruby-rack from version 2 to version 3. Besides the dependency madness, ruby-rack itself grew a couple Recommends, ruby-rackup an ruby-rack-session, which would already be enough to file MIRs - which happened, as other packages which used to depend on ruby-rack are now depending on these specific binaries as well (or they should be!). I was able to drive those MIRs without much hassle - including jumping ahead of Debian to bring the latest ruby-rack-session by that time, addressing a security bug.

* Besides the ones I drove myself, I helped nadzeya with the rust-hwlib MIR, providing hints and information, coordinating work with slyon when he was reviewing it, and kept in touch with mz2 during all of the packaging and MIR process.

Transitions

I have not driven transitions myself, but I have some related work:

* I have followed athos-ribeiro's work in the php8.4 transition, to learn how it works from tracking to uploading packages to bootstrapping packages (specifically circular dependency solving) and so on. I have myself added a couple overrides in the process , both sponsored by Athos of course: phpunit-global-state/7.0.2-3maysync2 and php-codecoverage/11.0.8+dfsg-3ubuntu1

* I worked in the smallest transition in Saint-Saëns! heh; I did the pacemaker merge listed above; pacemaker provides several libraries, on which sbd (and only sbd) depends on (libcib27t64 or libcrmcluster29t64 for example). As the major version bump on pacemaker had SONAME changes for those libs, the upload started a transition - so I had to do a no-change rebuild to make sure nothing broke: sbd/1.5.2-2ubuntu3. A transition for a single dependency but still.

* The php-related packages above (php-lorenzo-pinky symfony php-league-html-to-markdown php-tijsverkoyen-css-to-inline-styles) needed to be fixed as part of the libxml2 transition. The bugs were flagged in Debian/experimental, and I fixed them in Ubuntu, where the transition had already taken place. As a matter of fact, I have sent all my fixes upwards (to Debian and to upstream) and all of them were applied as the fixes for the bugs! (symfony upstream, and the other patches in Debian, because upstreams seem slow for the php specific things)

Other

* I recently have performed merge reviews for the Server team, following the standards defined in the Maintainer's Handbook. For example, I can highlight samba/2:4.22.2+dfsg-1ubuntu1 for ahasenack, and wireguard/1.0.20210914-3ubuntu1 for slyon

* I have shadowed athos-ribeiro in some activity related to +1 maintenance and patch pilot; I could help by performing reviews such as this one for opendnssec.

Areas of work

For now:

* php stack

* HA stack

* triage and bugwork for Server subscribed packages

Things I could do better

* +1 maintenance. I could dedicate myself more to the excuses page, as I'm sure I'm able to resolve some of the problems there.

* Besides excuses, I could take more responsibility on bugs when doing triages. I could try to pick more bugs to work on, to the extent of my knowledge and experience

* I could participate more in public channels, like Matrix for example, sharing the bits I'm working on, getting information, and potentially helping people as I develop and grow together with the community (:

Plans for the future

* GIT GUD

* Go for the things I could do better listed above.

* The php8.5 transition is coming! I want to upload the new php and drive the transition myself, which will be important both for the 26.04 LTS, and for my experience an knowledge. I also want to do good work on the areas of work listed above.

* Apply for MOTU / core-dev, to be able to help making Ubuntu even better and solidify my work with the distro.

* Involve myself more with Debian, sending more bugs/patches/discussions that way, to better integrate packages and reduce maintenance burden as possible

What I like least in Ubuntu

The whole infrastructure seems very fragile: builders, autopkgtest runners, and Launchpad itself suffer a lot from misconfiguration, lack of resources and random bugs. That makes contributions a mix of luck and Retry Engineering (tm) - where you need to click the same thing a few times before it just works. This is misleading for beginners, who can lose track of what is wrong (if there is something wrong at all) with their work, and has been quite tedious for long-term developers, who lose time not only waiting for their uploads but also on chasing infra bugs. This is being constantly improved though, through the work of the release team to the extent it competes to them, and the new Canonical Debcrafters team, who through feedback and active changes to the infra are able to mitigate the fires. I hope in the future it will be better for everyone.

---

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

Renan and I have been working together in Ubuntu Pro for the past 4 years. Renan used to work on the Ubuntu Pro client team, while I worked in the Ubuntu Pro backend. He left early this year to focus more on the server aspects of the distro.

He was always mindful of the big picture, not only in the technical sense, but also on the interpersonal aspects of software engineering. He can anticipate problems and help the team avoid them. And he is willing to find good compromises when needed for delivering something fast.

At this point Renan is the most senior member of the former Ubuntu Pro client team who is still at Canonical. He helps us package and ship it. The Ubuntu Pro client is a complex piece of software at this point because of the many distro quirks it must adjust for. Renan is my go-to-source for understanding all these quirks when I need something for my backend work.

-- alnvdl 2025-09-04 13:02:12

I had the chance to work closely with Renan on the MIR for rust-hwlib. He guided me through the process by helping to fill out the MIR bug properly and pointing me to the right documentation and examples. He was extremely helpful in setting up CI for the hardware-api repository so that we could test the Debian package build for each change.

Renan also tested the project thoroughly himself, reporting a number of bugs and following up on them well before the package was added to Ubuntu main. Another key area he helped with was organising discussions with the AppArmor team to ensure that hwctl had a good profile, which was one of the important TODOs for acceptance.

From my experience, Renan was proactive, knowledgeable, and supportive throughout, making the MIR process much smoother and more productive.

-- nadzeya 2025-09-05 10:50:10

---

Endorsements

---

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

Christian Ehrhardt

General feedback

a) Please fill us in on your shared experience Renan has been in our Team for some years now, he always had deeper interest in the Distribution itself. When working on the pro client he was the one dealing with apt special handling of increasing levels of complexity. Often discussing with Julian on the really tricky parts. From these days I happen to know that he is quite well in coordinating cross team as needed. He has since changed to distro work matching his interest and I'm happy to see him churn through bugs, merges, bug triage and more at ease and always in line with the code of conduct.

b) How many packages did you sponsor? I have not sponsored much, long ago I have to admit I sponsored wrong and recently only one package with sdb. that one was fine, but while I totally believe in what I've seen processed for bugs, merges and more - sponsoring is nothing I can judge well personally.

c+d) How would you judge the quality? How would you describe the improvements? I like the quality of his work, in the very early days there have been a very few non-great cases - but you know what he reached out, asked, he listened to feedback and now is on top of this. He has in my POV ramped up numbers and complexities of cases ever since, with the recent chance for dedicated work on the Distro giving him the chance to do so.

e) Do you trust the applicant? Yes I do, he is not bypassing the process or system, knows a lot already and a quick learner where he isn't aware yet. Furthermore I have always found him at the right balance of "asking when appropriate" - neither at the "ask all the time to annoy" nor at the "never ask and do bad things due to it". Which is just the right thing IMHO.

Overall, I'm in favor and support him fully for the application presented here.

Specific Experiences of working together

skip - outlined above.

Areas of Improvement

It is not so much the knowledge or skill, I'm tempted to say most of what I see here is close to qualify for a core-dev. Only some aspects miss a) numbers, which will naturally come by continuing his work and b) some things like transitions, which we also think will happen in the coming months. So his improvement is to please continue to prove his work with good uploads so we will soon see again for the next application here.

Bryce Harrington

General feedback

I've reviewed and sponsored work from Renan both currently on the server team and previously with his Ubuntu Pro (aka ubuntu-advantage-tools) work, and thus feel I have a gained a well rounded view of his work. More importantly, I find him trustworthy with a strong ethic of doing things correctly, taking review critiques as opportunities to learn. He never shies from a good technical argument, which he is happy to lose if the outcome is good engineering. He is similarly not shy about finding and flagging technical problems, and strives to be courteous in sharing his thoughts.

Specific Experiences of working together

Reviewing Ubuntu Pro releases was a huge challenge due to involving hundreds of commits; I tended to focus attention on the areas that interfaced with the system, and as Christian mentioned those were often areas that drew Renan's attention. So I had many opportunities to examine Renan's Python coding style and approach, and how he addressed intricacies of system-level interfacing. I rarely found anything worth mentioning, and recall finding his coding style clean, understandable, and correct (as far as I could tell). When I did find issues (even minor nits) he took my feedback seriously and addressed the issues reliably.

In joining the Ubuntu Server team, Renan has started from the bottom of the learning curve to becoming a packager, which I've followed, lent advice here and there, and provided review and sponsorship. Even moreso, Renan has been a regular reviewer to some of my own python development work, which I've highly appreciated - on a team more heavily focused on packaging than python coding it is sometimes hard to find co-workers willing to endure my dense Python branches, but Renan has not shied from the task! In fact, I will be passing maintainership of one of these projects to him to carry forward, and I feel my work is in great hands.

I'd also like specifically point out Renan's work on the PHP stack and transitions. Handling of PHP transitions has become a sort of trial-by-fire in the server team since it holds many tricky packaging tasks, and by the time an engineer successfully completes a PHP transition they will almost certainly have covered every skill expected of a core-dev! So, I was happy to see Renan take on this duty for exactly this reason.

Areas of Improvement

I think Renan's doing great on his journey. I suppose only advice is that in this job it is easy to get overwhelmed, taking on too much responsibility, and when one has core-dev the pressure to take on more and more gets pretty intense. So Renan: Look out not only for yourself but also your co-workers, and keep using your talent for advocacy to keep workloads sensible and fair such that the team avoids burnout.

Athos Ribeiro

General feedback

In the past 3 years I sponsored 42 uploads for Renan (15 if we count each SRU round for all supported releases as one) on 11 different packages where most, if not all, were under or related to the Ubuntu Server team.

FWIW, I have been training Renan on his packaging journey for the past 6 months. We have weekly sessions where we sit down together and discuss policies, go thrugh package build or test failures, migration issues, tools, etc. Due to our regular training sessions, I have been refraining from sponsoring uploads for Renan lately to reduce the bias and allow him to have different views of how the distro and its development work by having other developers to review and sponsor his work.

Renan worked in ubuntu-advantage-tools (the Ubuntu Pro client) for years, both in the upstream project and in the Ubuntu package. IMHO, that is one of the most challenging packages to perform SRUs for: even the smallest and simplest of the regressions may cause too much trouble for too many users/deployments and dealing with regressions may not always be straightforward.

If one tracks Renan's launchpad history, one will find out exactly what Renan describes in his application: it is clear how much improvement one can perceive over time on all his uploads, bug reports, SRUs, and other requests. It is also nice to see how committed Renan is into his Ubuntu journey and how much enthusiasm he is putting on it.

Renan is ready to get his upload rights for the Ubuntu Server packageset. As a core-dev and his co-worker in the Server team, I fully trust him with such rights. As his mentor, there is not much left (if any) to pass on other than the regular exchanges two core-devs may have between themselves. I also trust Renan knows where/when to ask or look for answers whenever he is in doubt.

Specific Experiences of working together

Here is a full list of packages I have sponsored for Renan: https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=*athos*&sponsor_search=name&sponsoree=*renan*&sponsoree_search=name

Other than ubuntu-advantage-tools, Renan recently worked with me on fixing the overall state of PHP in the archive during the PHP 8.4 transition for Ubuntu 25.04, fixed some broken PHP packages after the last libxml2 transition, and helped unblocking Ruby related issues we had after the 3.3 transition in Debian, in special with Ruby rack.

Areas of Improvement

I like how Renan sticks to what is written in our policies and documentation. Sometimes this led to very long discussions during our training sessions. This puts Renan in a very unique position to contribute to our documentation, which I would like to see him doing more often.

If Renan keeps dedicating his time to Ubuntu as much as he is at the moment, the volume of work/packages/issues he will be exposed to will naturally increase, which will help demonstrate all his knowledge for future applications. More specifically, it would be nice to see Renan leading or participating in a larger transition. This would likely expose Renan to a broader set of packages outside of the Ubuntu Server team umbrella, and I am sure the whole project would benefit from having Renan's expertise helping with the archive.

As a Ubuntu Server packageset uploader, I would like to see Renan performing more package reviews for the Server team (as per the teams' processes). Whenever he gets his upload rights, it would also be nice to see him sponsoring some uploads as well.

Finally, it would be nice to see Renan being more active in Ubuntu public channels as he mentioned in the application.

Andreas Hasenack

General feedback

TL;DR Unreserved +1 for Ubuntu Server Developer.

My initial work with Renan was around the ubuntu-advantage-tools package, for which he was upstream. This package really forged his knowledge of Ubuntu in so many different areas:

• autopkgtests
• SRU requirements
• Ubuntu package management (sources.list, gpg keys, repository signatures, upgrades, downgrades, ubuntu release ugprades, the list goes on and on)
• Dependencies
• Maintainer scripts
• Bug triage

By the time Renan came into the Ubuntu Server team, he knew all of this already. He just needed experience with other areas of the distro, and merges with Debian. Which this application shows he now has.

Specific Experiences of working together

Full list of sponsored packages

https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=*asenack*&sponsor_search=name&sponsoree=*enan*odrigo*&sponsoree_search=name I sponsored 8 source packages for Renan (I'm not counting the same upload to different ubuntu releases, like ubuntu-advantage-tools 27.11.1 to xenial all the way up to jammy.

ubuntu-advantage-tools

I sponsored several uploads of ubuntu-advantage-tools for Renan. This is a complex package, for which Renan was the upstream back then, and he had to deal with both upstream bugs, and packaging issues. As the sponsorships progressed, Renan got really good at spotting *ahead of time* issues we might have with the package, both from sponsoring and SRU point of views, reducing the workload of the sponsor and SRU reviewer.

ubuntu-advantage-tools, being such a critical package (seeded and in main), has shaped Renan's understanding of Ubuntu and all the risks associated with uploads to the archive, be it for the devel release, or an SRU all the way back to xenial. This also made him aware of all the tooling we have in Ubuntu: how to launch containers, VMs, build packages for older releases of Ubuntu, run tests in the cloud, and so much more.

php 8.4 merge

https://code.launchpad.net/~rr/ubuntu/+source/php8.4/+git/php8.4/+merge/490480 This was a simple merge, small delta, but where I asked in my review for Renan to improve a bit the "delta management".

Specifically, I asked to recheck if the dtrace delta was still an issue, which resulted in Renan filing https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110885 with debian.

The second point was a way for us to make a new delta acceptable to debian, which resulted in the salsa PR https://salsa.debian.org/php-team/php/-/merge_requests/23

Renan didn't have to ask me how to forward any of these to debian.

As we get more familiar with debian merges, the next step is to not only make our delta fit on top of the new debian upload, but also manage it. That means dropping where possible, forwarding where it makes sense, adding delta where needed. I think this PR shows Renan entering into this second stage of debian merges.

pcs merge

https://code.launchpad.net/~rr/ubuntu/+source/pcs/+git/pcs/+merge/488136 Normal merge, but there were questions about new dependencies and on-going MIRs. Renan had a very difficult stack to manage with these uploads (ruby), and this PR shows all the complexity he had to deal with in the devel release, and getting all these ruby components in.

Areas of Improvement

I wouldn't say improvement, in the sense that any of this was bad. My point is to jump into the next level for each one of these.

Debian merges

Always be mindful of delta management. Drop, add, and forward, where it makes sense. When adding delta, think about how it could be added in a way that perhaps Debian would also take it.

Documentation

Perhaps you can also soon start adding new content to the server guide

Autopkgtest

You have seen many autopkgtests results in your journey so far. You have seen how they can fail, how to trigger them, how excuses works. Next step: add new autopkgtests.

Lena Voytek

General feedback

At this point I've done 20 uploads for Renan, including a large version update to the pro client. Through these, and from working together on the server team, I can confirm he is ready for upload rights to the server package set. I've seen in merge requests and in person a focus on correctness while avoiding shortcuts.

Specific Experiences of working together

Here is the full list of sponsorships: https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=*lena*&sponsor_search=name&sponsoree=*renan*&sponsoree_search=name

The most extensive sponsorship I did was for ubuntu-advantage-tools 35 to all available releases. Despite it being thousands of lines of changes, I found only a few minor issues. See https://github.com/canonical/ubuntu-pro-client/pull/3342 for reference.

I've also sponsored smaller items for packages with fun names like php-lorenzo-pinky, and the prepared fixes have always been ready to go without issue. The fence-agents upload was also a great example of a well-prepared merge.

Areas of Improvement

I think that the experience provided here is certainly enough to show Renan is ready for Server package set rights. Focusing on the road to core dev, the next steps should involve driving transitions and sponsoring packages for others. I also agree that having a more public presence on Matrix would be great, especially through patch piloting and answering questions

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

---

CategoryPerPackageUploaderApplication