Application - Core Developer - Renan Rodrigo

Community Ubuntu Developer Membership
1

I, Renan Rodrigo Barbosa, apply for core-dev upload rights.

Contact Information:

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

  • I’d like to be able to mentor others to follow the same path

Who I am

I am a dynamic, dedicated, organized, focused, agile, versatile, flexible, creative, proactive, decisive, communicative, committed, and extroverted guy, but I’m not arrogant.
I add value, adapt to change, and focus on results. I have an easy time working in a team, a leadership spirit, good interpersonal skills, and a consistently positive mindset, except when I’m waiting for the results of a COVID test, then negative is better.
Throughout my career, I have always sought to share responsibilities, subtract differences, and combine efforts to multiply results.
I love facing challenges, taking risks, and meeting goals.
My best qualities are ethics and professionalism.
My biggest flaw is being too much of a perfectionist.

Oh no, wait,

that’s not me

This is me

Screenshot from 2026-03-27 10-41-46
Screenshot from 2026-03-27 10-41-46521×1012 73.4 KB

I am a software engineer working on the Ubuntu Server team. In the Server team, I currently work with the PHP stack, the HA stack (and a little ruby as part of that), and the Pro Client package maintenance. I am the current maintainer of ppa-dev-tools.

I have participated in the Brazilian qualifiers for WorldSkills 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 compatibility 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.

Now I have way more experience with packaging, and want to keep following this path.

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

I got involved in the development of Ubuntu as part of the day job.

Examples of my work / Things I’m proud of

Full packaging fun can be seen in https://launchpad.net/~rr/+uploaded-packages

For highlights on work done before 09/2025, please check my previous application (for Server Packageset)

A significant amount of what is there match the requirements for a core dev application, as stated in the feedback I got when applying there.

Since then, I have worked on:

Sponsoring!

Although most of the upload power I have now is directed to help my own business in the Server team, I could help others by reviewing and sponsoring their work: that’s true for team colleagues, as in jj’s openldap, and for peers from other teams too, such as in ceph 19.2.3-0ubuntu4 and the non-trivial ceph 20.2.0-0ubuntu1 uploads.

Package Merges and Syncs

There were a few syncs to remove Ubuntu delta. My very first one is open-vm-tools, and a couple more were sponsored for me (ruby-gelf and iotop-c).

Merge wise, I did work on:

Bug fixes and improvements

I did several bugfixes related to the bug triage work the team does for server related packages, and quite some more because of the PHP 8.5 transition. There is nothing very shiny, I don’t think I have fixed bugs which changed Ubuntu forever, but well, it ain’t much, but it’s honest work (:

I can mention I worked in some more libxml2 related fixes, as for php-easydrf, and double checked this HA related problem with date in rust-coreutils which Andreas fixed in kronosnet, but affected several other packages, for instance.

Interestingly, I did some patch pilot training with Athos, but because I have limited upload powers I could only partially help, as shown in MPs for coinor-dylp and mshr

I did some +1 maintenance with Athos too, but that was focused on the PHP transition mentioned later here.

As part of my work and triage duties, I was also able to file interesting bugs, like finding leftovers from previous php-related removals or finding missing rust-coreutils functionality affecting Ubuntu packages.

SRUs

Besides the devel bugs listed above, I worked on some bugs opened against stable releases, and also some backports. For example:

autopkgtest and dep8

As part of the regular work, and boosted by the PHP transition, the watch in the excuses page is doing well, thanks; besides that, same practice mentioned before of running dep8 tests locally before uploading/approving, making sure I investigate logs when they fail instead of blind retry-engineering.

Also, one of the problems for the iotop-c MIR (below) is that the package (just like the former iotop) lacked dep8 tests at all. I added them and sent them upstream, where they got accepted (: see iotop-c/1.30-1ubuntu1 and iotop-c/1.30-1ubuntu2 and then iotop-c/1.31-1

MIRs

Unlike last cycle, where MIRs were floating around to be caught, this time I had the opportunity to work on a single one, iotop-c.

It was my decision to pursue this, as iotop is not maintained anymore, and we should keep iotop-c in main instead. Details are in the MIR bug

As mentioned before, I had to add autopkgtests to the package, and someone needed to sync it for me later as it was universe and I can’t yet upload to universe, well well! heh

As part of this work I have also changed the seed for the MIR to be complete, as seen in the commit to seeds-platform, which you’ll have to clone to see locally, as git.launchpad.net constantly returns a 503 when trying to browse code :smiley: :smiley: :smiley:

Transitions

For the 26.04 cycle I drove and worked on the PHP8.5 transition. With the help from my mentor, Athos, I have led efforts to make sure the LTS has the latest PHP available before it’s released.

The first part of this effort was to communicate with Debian, as the transition had not started there yet. By contacting PHP maintainers on the Debian side, we learned that Debian was not going for it, at least soon, for $debian-release-date reasons, and Ubuntu would have to jump ahead.

Ondřej Surý, The PHP machinery maintainer in Debian, had PHP 8.5 prepared on Salsa though, and that was the starting point on our side. (php8.5/8.5.2-0ubuntu1)

Then, the transition was added to transitions.ubuntu.com, and triggered by php-defaults/99ubuntu1

There were some problems during the transition, of course, all of them kind of expected and worked around with a little help from my friends of course.

First, the transition timing made some entanglements (mainly with python3) happen. Although the overlap is small, there was a need for watching and coordinating package fixes for both migrations to work fine.

Then, a couple technical problems (:

  • Britney decided to take a nap for a few days during the transition. That led to a massive amount of delays everywhere, as the machinery needed for the transitions was stuck (: Waiting caused some anxiety, but once the service was back online we resumed the work without major incidents.

  • Other transitions and uploads caused the autopkgtest queues to go waaaaaaaaaaaaaaaaaaaaaay long; at some point in time we got a few thousand packages waiting in the ‘huge’ queue (you see? it became huge. HUGE!). That made the feedback loop for all the patches and fixes needed for the transition increase by more time than it would be acceptable… however, this was bad to everyone else as well, and was solved (by cleaning up the queues with some -f heh), putting everything back to normal at some point.

Then, as if it would not be enough, there were entanglements in PHP itself: as Debian updated packages and they got synced (whether automatically or by human hands :frowning: ), we ended up with 3 transitions at the same time: the PHP one I was driving, then phpunit (which is horrible because of so many circular dependencies), and symfony (which is always pleasant…). All of these getting major bumps at the same time was unfortunate, but with community and team help we ended up sorting out everything!

Another thing worth mentioning about the transition is: would not it be GREAT if I had more upload powers ?? hehehe

  • I had to ask for people to do no-change rebuilds for me. That’s something at this point I could do myself, just lacked the permissions. I did all the dirty work of checking what would need deeper fixes, and to have the karma and my name on it I had to ask people to sponsor NCRs. Oh, life.

  • When doing fixes to untangle the three PHP transitions, I could have done more with more upload power too. Not once not twice I have worked on something, quick fix, obvious or not, and then would lack the rights to upload it, then would open MPs asking for sponsors, just to see someone else (mostly locutusofborg, who I am very thankful to, for all the help!!) jump there and upload a fix. That is effectively wasting one of us’ time - if I could have uploaded things, Gianfranco would not need to spend time doing the same work, and we could have done a better work together to fix everything. To be clear I don’t feel anyone stepping on my toes, on the contrary: I wish I could have helped more, and I could not.

Concrete example: I have patched php-twig as part of the efforts to migrate phpunit, and sent a MP for someone to sponsor it, in the morning. Then in the afternoon, ta-da: php-twig/3.23.0-2build2 was there, and with the same change…

But life is not a strawberry, and I have of course made some small mistakes in my first transition. One interesting thing I overlooked was: the php build machinery has this piece of internal magic to fix binary package names depending on the base PHP version you’re building against. As I didn’t capture that at first glance, I ended up doing (requesting :confused: ) the aforementioned NCRs for a few packages, which would then have MISNAMED binaries in d/control :smiley:

For instance, the package ‘php-foo’ would describe, in d/control, a binary named ‘php8.4-foo’. But then the debhelpers would convert it at build time, and we effectively ended up having ‘php8.5-foo’ built!

All the context is in the php8.4 removal bug

Although for a ‘make a binary available and install it’ perspective this was fine, as the correct binaries are published, I ran into a couple inconveniences:

  • Some machinery on LP is not relying on the built packages, but in the .changes and .dsc files instead, and there you could still find ‘php8.4-foo’. Because of that, ‘php-foo’ would never be listed in the NBS reports, and we would end up with a broken (i.e. uninstallable) php8.4-foo package in the archive, with the same source appearing twice, with different versions, in the same pocket!

  • This effectively violates the Debian packaging policy. Graham noted it in the removal bug.

The solution was simple: update d/control for all the affected packages.

Guess what? another round of sponsorship requests (this time Athos did all of them, many many thanks again!)

All of this led me to a significant amount of learning and experience, and in the end made me even readier (readier?) for this application.

Areas of work

For now:

  • php stack

  • HA stack

  • Stable release maintenance of squid, openvmtools, and ubuntu-advantage-tools

  • Development of ppa-dev-tools, and maintenance of the snap

  • triage and bugwork for Server subscribed packages

Things I could do better

  • Sometimes I feel some soft skills need some polishing… I can be more organized (in the sense of not losing track of what is where), less pessimistic about the problems I see around, and more patient; ASAP may be different from NOW or FAST.

  • Another trait is that I usually go easy with stuff, even when it’s too serious. That sometimes puts me in a situation where people think I’m not giving the proper attention or importance to stuff, when I’m only trying to make the best out of it, with a little fun. Being more assertive, it is?

  • Time management is my passion.

  • [bonus] Like, I need to policy myself to, like, avoid the word ‘like’. I saw videos of me speaking and read the transcript of my packageset application, and I’m like: yeah this like that like, like what, like, all the time. I don’t like it.

Plans for the future

General

  • GIT GUD
    *

    image
    image390×472 87.9 KB

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

  • Involve myself more with Debian, sending more bugs/patches/discussions that way, to better integrate packages and reduce maintenance burden as possible - this was already a goal last time and keeps being a goal for the future

  • Improve the situation with the PHP packaging overall. Getting in touch with Debian and working together so we can try to fix the phpunit circular import horribleness (only relevant to Ubuntu honestly) and how pkg-php-tools sorts out the autoresolve of php-composer dependencies, which has been a burden for some time now.

  • Taking more responsibility in improving processes in Ubuntu

  • Mentoring new people so they understand the workflows / processes, responsibilities, implications of Ubuntu contributions, sharing my knowledge and experiences.

  • Serious +1 duties, which seem very important these days given the excuses page length

What I like least in Ubuntu

I have put that in my Server Packageset application, and it still applies, if not even more:

ohno

From my previous application:
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 ™ - 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 falls under 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.

As I have been uploading, another thing that bothers me is the lack of tracking upload-wise. I understand the policy of “one upload is one chunk of diff” but git has been around for so many years, and making sense of delta without context is still difficult sometimes. There are git-ubuntu workflows which involve rich git history, but not everyone is following that, which leads to your nice tree being changed to a single importer record when a security upload comes in. My part in making it better is using the git based workflows as much as possible, and spreading the word to motivate fellow developers to do the same. On the long run, some change in LP models could enforce git instead of enforcing old style single commits.

Endorsements and Comments

Hello friends, would you please (:

## 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 tak
5 Likes
2

I endorse Renan for Ubuntu Core Developer. I believe he can be trusted with upload rights to Ubuntu right now.

Specific experience of working together

I didn’t sponsor a particularly high number of packages for Renan (I count 6 ubuntu-pro-client uploads, back when it was called ubuntu-advantag-tools), however I was exposed to quite a lot of Renan’s work in my Server Team days, and I know that as an “upstream” maintainer of ubuntu-pro-client he had to deal not only with the packaging itself, but also with delicate apt / dpkg corner cases and quirks across different Ubuntu releases to ensure that things didn’t break at SRU time.

Developing Ubuntu Pro required Renan to interact and coordinate with several Ubuntu teams. In the spirit of Renan’s application opening paragraph, I will say that in this regard Renan set a great example for collaboration, commitment and focus.

As a Release Team member I reviewed and merged some of Renan’s work on hints and the transition tracker (to improve php tracking). Renan proposed high quality, well explained in in general ready to merge MPs. I have no concerns to raise.

1 Like
3

Sponsoring feedback

I have been mentoring Renan throughout his uploader journey for over a year.

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

If you chronologically navigate through Renan’s bugs and changes, you will clearly see how quality improved over time. He has great understanding on how the distribution works in general and pays extra attention to details.

On our early days working together, on ubuntu-advantage-tools, there were a few informal discussions on whether Renan should apply for Per Package Upload rights for ubuntu-advantage-tools. The conversation would usually converge to a conclusion on ubuntu-advantage-tools being such a complicated package, entangled with other packages, and with such a great impact, that no one should have PPU rights on it. Instead, they should become core developers to be able to upload that package.

I trust Renan is ready to upload ubuntu-advantage-tools on his own. I trust Renan to get his Core Developer upload rights now.

Specific experiences of working together

I worked with Renan on sponsoring his Ubuntu Pro uploads for years before he started working in other areas of the distro. After that, I started mentoring him throughout his upload journey.

Our latest experience working together was on the PHP 8.5 transition. This was a long, unusual transition:

  • We moved ahead of Debian, but not before Renan reached out to the Debian PHP team to make sure they did not want us to work on the transition through/with them.
  • The transition got quite entangled with other PHP reverse dependencies (non-library) transitions such as phpunit. There were some bootstrapping involved which made the transition much longer and more interesting.

With this experience, there is nothing left for me to guide him through other than regular core-dev exchanges we often have among core-devs given everybody’s unique expertise.

It is also worth mentioning that Renan has great communication skills and he sure knows how/who/where to ask whenever in doubt.

Areas of improvement and next steps

I do not have anything specific to point out here. From now on, I believe Renan could start touching other areas of the distro, doing more +1 maintenance shifts, start sponsoring uploads for others and possibly mentor other future core developers.

4

Sponsoring feedback

I endorse Renan’s application for Ubuntu Core Dev.

Renan has been exposed to all tasks a Core Dev is expected to perform, and even more. I’ve seen his work in:

  • transitions
  • SRUs
  • MIR
  • MRE (special SRUs)
  • autopkgtests
  • excuses inspection
  • update_output.txt analysis
  • steady bug triage
  • colaboration with upstream

He definitely went outside his “comfort zone” that was ubuntu-advantage-tools, and demonstrated competence in many other areas of Ubuntu, like the HA and PHP stacks. That being said, ubuntu-advantage-tools was already very demanding and required near core-dev knowledge due to the interaction points with an Ubuntu system.

These are my sponsored packages, the fist one being from 2022: https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=*asenack*&sponsor_search=name&sponsoree=*Renan*Rodrigo*&sponsoree_search=name
About half were indeed ubuntu-advantage-tools, due to his work in that team. But afterwards we see packages from the HA stack, and PHP.

Specific experiences of working together

The ubuntu-advantage-tools package is where we can start to see a core-dev in the making. Having to deal with multiple ubuntu releases and each with their own quirks, and complex maintainer scripts (postinst in u-a-t is quite complex). Of course, Renan wasn’t the only one working on this, but was frequently the driver behind the SRUs and had to know, AND FIX, all that was being changed in each upload.

I think tcpdf is a good example of how a fix can evolve given different inputs. The first review from me highlighted that the fix was too broad. It had been submitted upstream at the same time, and discussions happened, and the fix was fine tuned based on this original feedback, and work with upstream. This is how it should be: we start with a merge PROPOSAL (emphasis mine), discuss, collaborate, and end up with a better fix. And this is how Renan works.

Areas of improvement and next steps

With more power, comes more responsability! Renan will be in a good position to help Ubuntu move forward. His experience in the PHP transition will be invaluable helping untangle other transitions, and nasty migration problems and NBS packages that are plaguing Ubuntu lately.