Hello! I’m Antoine Lassagne and I would like to apply for Ubuntu Contributing Developer
- Name:
Antoine Lassagne - Launchpad Page:
https://launchpad.net/~antoinelassagne
I am applying because:
- I’d like to help the Ubuntu project grow
- I’d like to continuously make progress on my journey with the Ubuntu project, for both personal and career growth
- One day I’d like to reduce the burden on my sponsors, sponsor others, help with the packages in whatever ways I can. I want to help delivering open-source operating systems to everyone.
Who I am
I am french and I’m based in Versailles. I’ve always be passionate about playing around with computers and hardware in general. I’ve worked in the automotive industry, in robotics, and I’m now working at Canonical, and I still love what I do!
On the personal side I’m married to a wonderful wife and I have 3 kids, aged 3, 2 and 0. When I’m not working, my wife would say that I’m still working. But not only with computers, I also love electronics, woodwork, any DIY discipline (including cooking, does that count as DIY?), and sport. It’s getting more and more difficult to find time between work and kids, but I’m happy when I’m busy 
My Ubuntu story
My first Ubuntu experience was a triple boot windows-nattynarwhal-macos on a macbook. I was so amazed to receive a CD for free at that time. With no wifi drivers out of the box, of course.
Then I never stopped using Linux, and mostly Ubuntu. In personal projects, in containers, in servers, on every computer I have, and of course on anyone’s machine when one dares to ask me (or not) to install it. Or when I’m helping people with the’re computers, I usually install them Ubuntu.
Now I work at Canonical in Partners Engineering. We’re in charge of improving the Ubuntu / Linux experience for specific partners. That makes me touch a bit of every userspace packages that are customer-facing in the distro.
Examples of my work / Things I’m proud of
I’ve been working on a little bit of everything. This is a non-exhaustive list of a few noticeable packages I’ve been working on.
- Some package updates: wpa 2.10 to 2.11 was an important one for Wifi 7 support. I was my first update with that many tricky patches. I’ve also done more simple one, sometimes on debian like vulkan-memory-allocator,
- A lot of SRUs. Some were by the book, some where a bit more wild. For example on this very uncommon wireplumber one, the impact was visible and the patch required to be entirely rewritten to apply to Noble. All these SRUs showed me how stability is (and should be) the only focus when backporting patches. They also made me build up my experience and confidence with the tooling. It involved alsa-lib, livecd-rootfs, gnome-remote-desktop. I also had SRUs blocked, for livecd-rootfs and wpa, and refusals taught me just as much as accepted ones.
- I’ve sometimes helped fix packages without directly being the one working on the update, when I had the opportunity to help, like with network-manager or vulkan-tools
- Some end-to-end patching. That involved developing the patch, submitting it and having it merged upstream, pushing it to devel, SRU’ing it. For example network-manager, or this in-progress gnome-shell one, or this other network-manager
- Some NEW packages: spirv-reflect is the one that landed already, and a few others are in the process (vulkancapsviewer, directxshadercompiler, dgx-desktop-sbsa-gwdt-loader). I had the 3 vulkan ones open as ITP to debian, with ongoing sponsorship.
I’ve been also involved in maintaining backported versions of ~12 vulkan packages for nvidia. They want the cutting-edge on Noble, but that’s not how LTS and SRUs work. So to keep them happy and not break anything, we make sure that ubuntu/devel has the cutting edge packages and backport them in a noble PPA, with some QA processes along the way.
Areas of work
My work on partners machines make me interact with the release management team, to figure out the best way to customize the distro without impacting other users and to build images the right way.
My work on various userspace packages make me interact with the uploaders, sometimes to get some help about how to tune behaviors, sometimes for opinions about bugs, or for their knowledge of a given package, and of course to get sponsored.
My work on early hardware enablement makes me interact with the teams in charge of testing and certifying the distribution, and I’m interested in making these process always better.
Finally, my work on new machines makes me interact with the kernel team and the OEM team, that are responsible for delivering an optimized experience for partner’s machines. Here again, understanding the big picture is essential for ensuring a transparent and optimized compatibility across the broadest possible range of devices.
Things I could do better
I clearly need more experience in packaging, all the aspect of it. I’m still learning so much. My journey learning the tooling seems to be a perpetual learning curve. In particular I’m not comfortable enough with gbp to my taste. I also want to master my understanding on how we test Ubuntu, at package level with autopkgtests but also at distribution level with GUI testing and certification suites.
Plans for the future
General
I will not have new permissions with this application, this is only one step forward. I will continue what I do, try to help wherever I can, and in particular on the project that I’m responsible for. That will involve upcoming arm64 hardware from Nvidia. I will be especially careful about how these devices behave with Stock Ubuntu compared to Ubuntu-based custom distributions shipped by Nvidia.
I’m also willing to do some more packaging work about pretty much anything, where resources are needed. We recently discussed a proof of concept that would replace the Bluez bluetooth stack with Fluoride, that I’m going to be part of.
What I like least in Ubuntu
Working on the distribution involves a lot of process and tooling sometimes competing with each other. Working at Canonical helps, but that should not be the case. It only means that community members are silently suffering even more. Thankfully the documentation recently got better.
I don’t like that some machines need custom Ubuntu images to work, I’d like to be very careful about enabling all the hardware on one single generic image. This is not specific to Ubuntu, but definitely something that would add value to the users.
Endorsements and Comments
Ask your sponsors and people that closely worked with you to use the template below, and reply to your application with their packaging endorsement (sponsors) or comments (anyone including sponsors).
## 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?