Simon Poirier | Core Dev Application

Community Ubuntu Developer Membership
1

Simon Poirier | Core Developer Application

I, Simon Poirier apply for core-dev upload rights.

I understand going straight to core-dev may be a huge leap. However, despite avoiding to formally apply for contributing developer for so long (for no particular reason), I believe I have been a solid contributor so far and have put the work expected to prove myself in that regard.

Contact information
Launchpad ~simpoir
Libera simpoir
Matrix @simpoir:simpoir.com
Discourse @simpoir
Askubuntu simpoir
Email simon.poirier@canonical.com simpoir@gmail.com

Why I am Applying

  • I am confident in my understanding of tools and processes around Ubuntu, enough to feel at ease sponsoring other’s contributions when I believe them to be correct.
  • I want to be able to support other contributors as peers, instead of always being in a situation where I need them to sponsor me and not being able to give back.
  • I want to mentor other contributors-in-the-making.
  • I want to help reduce delays for some work to get sponsored. Specifically, I know some team’s work (e.g. landscape, cloud) don’t always get timely attention from sponsors and I want to help rectify that.

About me

I started as a Debian (slink!) user around 1999, after experimenting with the more minimal distros at the time (ulinux and such). I have also done my fair share of distro-hopping (and trying configurations before their time, like coLinux) up until 2010. After I graduated, I got introduced to Ubuntu by colleagues and I got to think “this is pretty good”, making me settle on it up to the present. Nowadays, I appreciate the opinionated nature of Ubuntu, of trying to keep efforts concerted to create a solid all-round experience which will appeal to even non-technical users.

My contributions to opensource are scattered. I enjoy solving problems, digging into how things work, and helping people around. I seldom hang around on IRC (still), Reddit and StackExchange to answer people queries and learn something while doing it. Daily, I get to contribute, to make use of my experience, and to raise the bar, thanks to my role at Canonical.

Code-wise, I’ve started developing in the 1990 with basic, turbo pascal and some C. Although I was mostly exploring and playing around back then (most of that code is long-lost), some traces still remain. Moving on, I’ve been developing with python for what feels like ages, starting with python 2.4 around year 2005 with blender scripting. I enjoyed the language growth since. I kept at it during my degree, despite all the pushback to switch to the more mainstream C++ java and ruby. How the tables have turned! Nowadays, I’ll generally write rust when I can, as I think it is one of the nicer language, toolchain and community (setting aside the packaging story).

Outside of code, I enjoy cycling, running, baking, swing dancing, overengineering my own infrastructure and playing music. I like to experiment. I take the least walked paths, sometimes leading to unseen wonders; other times to dead ends.

Contributions

Other contributions:

  • I still subscribe to and occasionally take time to answer questions on Askubuntu, mostly around Landscape. Although I’m not directly involved with that project, I think I still have a positive impact on users and the community.
  • I’m usually responsive to queries on libera.chat#ubuntu-cloud and matrix #ubuntu-cloud:ubuntu.com.

Areas of work

  • glibc maintenance
  • triage and fixing of Debcrafters packages

What I could do better

My participation to on some channels (matrix, discourse) is still spotty. I often feel overwhelmed by the number of threads all over the place and mostly keep participating in focused topics which are LP bugs/merges. I’ll sometime jump in matrix answer a few queries, then disappear for days. I aim to do more than that on the long term
Also, multiple times I’ve tried upstreaming many of my fixes, but I don’t always follow on those threads in a timely fashion.

What I hope we fix in Ubuntu

  • To improve tooling related to Ubuntu contributions, in order to remove irritants and facilitate accessibility of contributions.
  • I also think we have an opportunity to diversify our documentation. Text reference is great, but I think we could cater to different demographics by having streams of what it looks like to e.g. file a bug, fix a bug, verify SRU, etc.
  • I’m a firm believer in code review. Upload privileges shouldn’t allow one to bypass review.
4 Likes
Ubuntu Developer Membership Board Agenda
2

I have only sponsored two packages for @simpoir, so I don’t consider that enough for a full endorsement, but I wanted to leave a comment anyway.

Sponsoring feedback

Not much to say here, but at least the two packages I’ve uploaded were very well prepared, including tests builds in PPAs, and @simpoir also took the time to consider whether the deltas could be dropped or not. That’s not a lot of experience, but that at least shows no blocker to me, and even expresses some good attitude with regard to working with upstream.

Specific experiences of working together

I now realize it’s unfortunate I did not leave any trace on LP, but there was this bug prior to the Resolute release, where many flavor images were not building due to some dracut vs initramfs-tools changes. Simon jumped on the problem and proposed some fix that eventually got merged.

The way I was involved in that is because as part of the Release Team, I was following very closely the situation, and was probably the one that sent the early pings about the issue. I participated in some Matrix discussions at the time (look around 2026-04-01), and I remember Simon had dug deep enough into that mess to have some local setup to reproduce, build, and test images builds using livecd-rootfs, which says a lot about his skills (especially at the time!).

On a different topic, despite us not being in the same team at Canonical, I remember many good technical discussions (and less technical ones as well) during the company sprints, and I fully trust him to be an exemplary, careful, very reasonable developer when he gets upload rights.

Areas of improvements and next steps

I guess I’d like to see more of him on the various communication channels, like Matrix or Discourse, but maybe I’m just not hanging out in the right threads.

3

I endorse Simon for Core Dev.

Sponsoring feedback

I have sponsored many packages for Simon. He has learned a lot about Ubuntu packaging and processes over the last year or so, and he his doing high quality work. He has been doing good work around Ubuntu for a while, so diving in and learning more about the distro and packaging has come easily to him. I trust Simon as a Core Dev.

Specific experiences of working together

I sponsored this fun bug fix, which demonstrated Simon’s ability to triage tricky issues in package upgrades, engage with upstream, and develop a fix.

I sponsored a handful of merges, and these have demonstrated his grasp of this process. A couple examples:

Most notably, he has recently stepped into the difficult role of maintaining glibc, and I have sponsored that package for him a couple times:

Areas of improvement and next steps

A lot of particular care needs to be taken when working on packages like glibc, so I look forward to seeing Simon continue to learn about that package and engage with upstream. As he has noted, I think he could be more present on public channels. He should start to work into the Patch Pilot rotation, which will have the added benefit of requiring more present on Matrix.

4

I support Simon’s application for Core Developer. I have experience working directly with Simon, and I have no concerns about trusting him with upload rights to main.

Sponsoring feedback

I sponsored a handful of uploads for Simon, all merges into Resolute: paramiko, ghostscript, devscripts, and nextepc. The packaging work was consistently well prepared: Simon evaluates the existing Ubuntu delta carefully, drops it when it’s no longer needed and documents the rationale when he keeps it, and tests his changes before asking for a sponsor. I never had to send anything back for rework.

Specific experiences of working together

Beyond sponsoring, I had several occasions to discuss distro work with Simon, in particular around autopkgtest. More generally I’ve reviewed and discussed his work across merges and proposed-migration fixes, and he is good at keeping the bigger picture in mind, asking for feedback when unsure rather than pushing through.

His handling of the 2.43-2ubuntu1 merge glibc merge, with accompanying FFE, the pre-emptive test rebuild and FTBFS bugs filing is good example of the kind of judgment I’d expect from a Core Developer on a sensitive package.

5

Sponsoring feedback

I’ve sponsored a few package updates for Simon during the Questing and Resolute cycles (build fixes, merges, no change rebuilds for transitions he worked on). His work has been solid on those changes, technically right, well documented and following our processes.

I’ve also watched Simon prepare the glibc 2.43 update for Resolute and review the test rebuild results in preparation for the upload. Glibc isn’t an easy package to work on and Simon followed the upstream project, handled the merge and dealt with the issues we hit on some architectures. He showed a solid understanding of the problems he worked on and a rigorous approach while working on the fixes.

Even if the number of uploads I’ve directly sponsored is limited, I’ve worked enough with Simon over the past cycles to have confidence that his understanding of the Ubuntu processes and his technical/packaging abilities are sufficient for him to be trusted for CoreDev.

I’m also confident that he would ask for input before uploading if he had doubts about some of his changes.

+1 from me to his coredev application

Specific experiences of working together

Listing some of those uploads I sponsored

https://launchpad.net/ubuntu/+source/libburn/1.5.6-1.1ubuntu1
https://launchpad.net/ubuntu/+source/dput/1.2.4ubuntu3
https://launchpad.net/ubuntu/+source/edk2/2025.11-3ubuntu4

Areas of improvement and next steps

While Simon did good work on getting the new Glibc in Resolute, I think his communication around that important update could have been better (e.g., doing a post on Discourse about the incoming update, being more involved on Matrix around the time of the landing where some issues were discussed and also reporting more build issues from the archive test rebuild to upstream/Debian/Ubuntu).