Application - PPU for media packages - Charles

Community Ubuntu Developer Membership
1

Contact Information:
Name Charles
Launchpad Page https://launchpad.net/~charles05
Matrix username @charles05:ubuntu.com

I am applying for a PPU to,

  • gstreamer1.0
  • gst-plugins-bad1.0
  • gst-plugins-base1.0
  • gst-plugins-good1.0
  • gst-plugins-ugly1.0
  • gst-python1.0
  • gst-rtsp-server1.0
  • gstreamer-editing-services1.0
  • gst-libav1.0
  • pipewire
  • wireplumber
  • gst-thumbnailers
  • alsa-lib
  • alsa-ucm-conf
  • alsa-utils

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

Who I am

I’m Charles, a software engineer at Canonical focused on the multimedia stack for Ubuntu Desktop. My day-to-day involves maintaining GStreamer, PipeWire, WirePlumber, and related packages, as well as triaging and fixing audio/video bugs across the stack. Before joining Canonical I spent most of my career building software on top of Ubuntu, so I came in as a heavy user of the distribution before becoming a contributor to it.

My Ubuntu Story

I first installed Ubuntu somewhere around 2008 from a CD stuck to a magazine. I’ve distro-hopped a fair bit since out of curiosity, but Ubuntu has been the base for most of my professional work. I joined Canonical last year and have been contributing directly to the distribution since.

Examples of my work

Areas of work

I’ve mostly worked on multimedia related packages as seen above. I’ve also helped with GNOME packaging, specifically GNOME Remote Desktop, Nautilus (GNOME Files) and LocalSearch (formerly Tracker Miners). I’m very grateful to the sponsors who have helped me with the uploader journey, and colleagues that have reviewed by work, in particular,

  • Sebastien Bacher
  • Alessandro Astone
  • Jeremy Bícha
  • Mate Kukri
  • Didier Roche-Tolomelli
  • Ken VanDine
  • Daniel Van Vugt
  • Marco Trevisan

Things I could do better

I could do better building out my understanding of Bluetooth and the kernel audio stack, since these are sore spots in the user experience today. I should get more involved in Debian contributions, making sure my Ubuntu-focused fixes are shared there. While I consider the core changes I’ve made have been accurate, I feel I’ve made too many mistakes handling the “metadata”; things like changelogs, LP bug references, and the like. I’ve been working to improve my local workflow to address this.

Plans for the future

General

I plan to continue maintenance and triage of the multimedia components I’ve applied for PPU privileges here. I’d also like to improve our Desktop UI for audio configuration once I build more experience there. There are many useful features in PipeWire/WirePlumber that are hard for users and contributors to discover; the documentation is sparse and the configuration language is tricky. I’d like to help improve that situation.

What I like least in Ubuntu

I joined when the new documentation effort was underway. My initial struggle was a lack of consistency in packaging workflows across different components, and a “choose your own adventure” approach to tooling that was difficult to navigate even as a Canonical employee with direct access to experts. For community contributors the barrier is process difficulty rather than technical complexity, which I suspect costs us contributions. The new documentation is a big step forward and I hope on-boarding is easier today than when I started. I’d like to contribute to that effort where I can.

I also find Launchpad can be awkward to use compared to forges like GitLab and GitHub, and the workflows they’ve standardised in the wider community.

Endorsements and Comments

Please leave your endorsements and comments following the template below, it is much much appreciated!

## 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 take, the next things they likely have to learn and the next mountains to climb?
4 Likes
2

Sponsoring feedback

Charles has recently joined the Canonical Desktop team and has picked up packaging at a rapid pace. In this time, I’ve sponsored 21 uploads for Charles; they’ve always been well receptive to feedback and they’ve demonstrated incorporating such feedback in their following work.

Charles now has a great understanding of debian packaging, both conceptually and practically in dealing with more advanced features of dpkg and debhelper. This was well demonstrated in the handling of the gst-plugins-bad1.0 binary packaging split that Charles drove from start to completion.
They’ve also demonstrated understanding of autopkgtests and have contributed new tests and improvements.

Charles clearly meets and exceeds the technical knowledge requirements for the multimedia packages they’re applying for, and they’re already handling most of the bug management for said packages.

I trust Charles not to do anything silly before asking.

Specific experiences of working together

The most impressive work I’ve shared with Charles is the gst-plugins-bad1.0 packaging split: https://salsa.debian.org/gstreamer-team/gst-plugins-bad1.0/-/merge_requests/22. The job doesn’t really get much more complex than that, and Charles has handled it masterfully.

Areas of improvement and next steps

I’d like to see more SRUs from Charles. The few examples listed in the application were handled at the very beginning of their journey and thus were rightfully lead by their sponsors. I’d like to see demonstrated understanding of the SRU process as it continues after the upload.

I haven’t sponsored library transitions for Charles, which might be an area to get more familiar with next as it might become relevant for their uploads.

2 Likes
3

Sponsoring feedback

How many packages did you sponsor?

I reviewed/sponsored around 30 uploads for Charles over the past cycle. Those included:

  • PipeWire updates, fixes, and merges.
  • GStreamer stack updates and merges.
  • The split of gst-plugins-bad and the MIR for the new gst-plugins-extra. This change was a complex piece of work that had been in the desktop team backlog for years, with the goal of getting rid of our distro patches by moving plugins from gst-plugins-bad to gst-plugins-good. Charles did impressive work there and managed to push the transition through for the LTS, allowing us to get gst-plugins-good1.0 in sync with Debian again and lowering maintenance headaches.
  • Packaging of the new gst-thumbnailer, which was part of the transition from Totem to Showtime.
  • The port of software-properties to GTK4.

How would you judge the quality?

Charles’s work has been of very high quality. He has read the Ubuntu documentation and demonstrates a good understanding of our processes. His merges have been done using the git-ubuntu workflow, for example.

He shows attention to detail, and his changelog entries are quite descriptive. He follows test plans (also contributing to improving them) and provides these details in the Launchpad bug reports and sponsoring requests.

He understands the Ubuntu processes well and has demonstrated this across a variety of MIRs, SRUs, and FFes. He has been following up on his uploads, watching proposed migrations, and working on fixes to ensure his uploads can migrate out of proposed (including helping to finish some transitions). He works with upstream and in Debian as appropriate. He has also been triaging Launchpad bugs for the audio components, where he has demonstrated a solid knowledge of the audio stack.

Do you trust the applicant?

Yes, very much. Charles is clearly an expert in the multimedia stack and has demonstrated that he also understands packaging and Ubuntu processes well. He also doesn’t hesitate to ask questions when he’s unsure about something.

Specific experiences of working together

Areas of improvement and next steps

I think Charles is well on his journey to getting more upload rights. The multimedia stack is his main focus, and the PPU is a logical first step. However, as part of the Canonical Desktop Team, he is also helping with updates, fixes, and merges for desktop packages. He has shown interest in learning more and helping at the distro level, for example with the +1 rotation.

I think he should be able to continue with Desktop packageset rights for the next cycle, and eventually Core Dev once he has a bit more variety in packages and has handled a few more SRUs, FFes, and transitions.

1 Like
4

Sponsoring feedback

Whilst I haven’t sponsored the greatest number of packages for Charles, the work I have reviewed has consistently been of high quality, and I have every confidence in their abilities across areas I haven’t personally sponsored as well.

Specific experiences of working together

I have worked with Charles through the Ubuntu Uploaders program at Canonical, reviewing a broad range of Ubuntu development topics: from technical packaging aspects to processes such as SRU, MIR, and freezes. Charles picks things up quickly, has needed little to no guidance, and has hit the ground running in virtually every area we’ve covered.

Areas of improvement and next steps

For this PPU application, I consider Charles ready, and I have no specific improvements to suggest. I also believe Charles has the skills to achieve full Core Dev rights in the near future; more sponsored work outside the Desktop domain would help demonstrate their abilities more generally, but that is a observation about breadth of evidence rather than any concern about capability.

1 Like