I, Alessandro Astone, apply for Ubuntu Contributing Developer.

I am applying because:

• I'd like to get some recognition and trust from the community, and not just that of my employer.

• I'd like to show my engagement on the path towards upload rights, for which I'm aiming to join the ~ubuntu-desktop delegated team.

Who I am

I am a Software Engineer specialized in operating systems, and more specifically the Linux userspace.

I started getting involved in open-source software around 2018 with LineageOS, the #1 community-made custom Android distribution. There I contributed to the build-system and common system frameworks, and ended up becoming the maintainer of the Recovery OS, as well as a few device ports. This was my first experience being part of and, in some sense, lead a large and distributed open-source community.

Around the same time I started using Fedora Linux on my home workstation, with the KDE desktop. As the little bugs annoy the software tinkerer, eventually they'll want to try and fix them, and so I did. I started participating in the IRC chats and contributing fixes to the packaging, and eventually I became a member of the KDE-SIG where I help maintain the large KDE desktop stack in Fedora. This is where I gained a large experience with packaging software with what we now call the "traditional" package managers.

I've always enjoyed contributing my fixes upstream in order to benefit all users of the software, and thus after sustained contributions I became an upstream KDE Developer.

I'm also the primary maintainer of the Waydroid project, which is a container-based approach to run Android applications side-by-side GNU/Linux applications in your GNU/Linux desktop: this is where I gained experience working with the Wayland windowing system.

All of that to say that I end up getting involved in too many things; but I love it and it's great fun!

My Ubuntu story

My first sustained interactions with Ubuntu must have been around 2018, where I was using an Ubuntu VM from a Windows host in order to compile the Android operating system. Ever since, I've been using Ubuntu in VMs or containers for some of my software tinkering.

My second notable interaction with Ubuntu comes from being the maintainer of the deb package for Waydroid, although that's hosted on a separate APT repository and not in the Debian/Ubuntu archives.

Finally, I joined Canonical's Desktop Team in June 2024, which is when I really started contributing to Ubuntu. It's been interesting to explore the Ubuntu culture and processes, as someone coming from other different communities. I've grown to truly appreciate the attention to detail that comes into every package upload.

My involvement

Examples of my work / Things I'm proud of

• I've written manual test plans for Ubuntu Desktop components:

  • evolution

  • gnome-settings-daemon

  • gnome-calculator

  • gdm3 (partially)

• I've handled merges from Debian. Some examples of non-trivial merges:

  • brltty for which we track a diff in systemd/udev rules to handle brltty being pre-installed but not always enabled.

  • gnome-session whose patches for defining an Ubuntu desktop session needed non-trivial rebasing.

• I've handled FTBFS issues with the archive rebuilds:

  • gtk2, gtk3, libssh, libgphoto2, gnome-settings-daemon, libblockdev, etc...

• I've packaged one new package from scratch:

  • adwaita-icon-theme-legacy

• I've added some autopkgtests:

  • wsdd (1), wsdd (2)

  • exfatprogs

• I've handled a few MIR requests:

  • wsdd (partially)

  • exfatprogs

• I've handled one library transition in both Debian and Ubuntu:

  • poppler (Ubuntu)

• I've handled many SRUs

• I've closed too many bugs

Areas of work

I've been working mostly around Ubuntu Desktop components, especially - but not only - graphics related components like Gtk, GDM, Mutter, GNOME Shell, and the graphics drivers. This includes sending fixes to the GNOME and Debian upstreams, when relevant.

The source for choosing where to direct my focus has been the Launchpad bug tracker, as well as the errors.ubuntu.com crash collector.

Things I could do better

I would like to hang out more in the public channels (mainly Matrix) to engage with users. I do feel a general lack of community engagement, but I am not doing much myself to improve it - outside of responding to Launchpad bug reports that is.

Plans for the future

General

I will continue to help packaging and integrating the latest GNOME releases into Ubuntu.

I will continue to provide good quality insights and patches to the Ubuntu bug tracker.

I'd like to eventually get upload rights in order to reduce the burden on my sponsors, and accelerate the throughput of fixes.

What I like least in Ubuntu

I don't like how most SRUs end up being verified by the author of the patch, because nobody else shows up to test. That's quite pointless, as presumably the author of the patch has already verified that it works. What's extremely important is feedback from users running the most diverse setups to test for regressions and for edge cases that the author/SRU reviewer didn't catch. And this includes both manual feedback from users, and automated feedback.

I would personally attribute the lack of feedback from users to:

• a generic lack of engagement in public channels, that separates the developers from the users.

• a sub-par experience for discovering updates that are in testing. A launchpad bug tracker is well suited for tracking an individual bug, but not for generic and mass regression testing. Please check out how the competition does update discovery and testing bodhi, which I find to be really good!

On the other hand, here's a few examples of missing automated feedback:

• the errors.ubuntu.com tracker may have received a new crash report that triggers after the patch, but this feedback is never surfaced to the developers during the testing phase so it will only be discovered after the update is released, or in phasing.
• autopkgtests are only run after the upload has passed the SRU team review, which takes valuable time and effort; detecting an autopkgtest failure before the SRU review would spare the need for a second review.
• we're lacking an OpenQA-like style of integration testing where the main desktop use-cases are automatically tested for every update, gating the update from being promoted.

I must say these are large and process-level things that I don't have a concrete proposal for; just some directions I would like to see Ubuntu move towards.

Something else I don't like is how easy it is remove packages that are critical for the system. For example: it is too easy to remove the gnome-shell package from an Ubuntu Desktop install. I believe this should be unavailable to users, until they modify some APT config. An idea that I want to propose to address this is that APT should always by default refuse to remove the metapackage used for installing Ubuntu, for example the ubuntu-desktop metapackage when installing Ubuntu Desktop.

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

Endorsements

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

Marco Trevisan

General feedback

Since the moment Alessandro joined the Ubuntu Canonical Desktop team, he immediately had a great impact on the team work and on the contributions that we both do to GNOME and debian (our direct upstreams) and of course to ubuntu itself.

He's very energetic and pushes to improve and modernize ubuntu a lot, and this is much appreciated.

He has driven already a transition and he's been really effective and high quality in all the work he did for ubuntu.

I sponsored various of his mutter, gdm, gnome-shell and gnome-initial-setup changes Alessandro did which fixed important issues for our users.

All these with just few minimal changes required, so I've to admit that my level of trust become quickly very high.

Specific Experiences of working together

Sadly I've not a full list of such uploads as normally, as per team-behavior - we still "finalize" the changes that have been proposed to salsa, but here's a good list:

• - https://salsa.debian.org/groups/gnome-team/-/merge_requests?scope=all&state=all&author_username=aleasto&merge_user_username=3v1n0

Areas of Improvement

As it's a matter for all the uploaders, it's important sometimes to focus even on the most minimal details and sometime sacrifice the time for quality, this is always happening in Alessandro's work, but it's a reminder for the future.

Julian Andres Klode

General feedback

I have not "sponsored" packages for Alessandro, but I've worked a bit with him on the unattended-upgrades stuff and I remember a whole bunch of desktop issues where Alessendro was the one to pop up and help, and I really appreciate his energy and enthusiasm, and I can't complain about the quality of the work.

Specific Experiences of working together

Please add good examples of your work together, but also cases that could have handled better. * https://code.launchpad.net/~aleasto/ubuntu/+source/unattended-upgrades/+git/unattended-upgrades/+merge/480771 - this is of course only part of the story, the rest is in internal specs and private conversations.

* https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2083538 - Alessandro stepped up, found the bug and bisected a fix in mesa, and uploaded fixed packages.

Areas of Improvement

I'll have to leave this for others to comment on.

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