Contributing Developer application - Alessandro Astone

[Alessandro Astone]

On 04/04/2025 08:02, Simon Quigley wrote:
> Hi Alessandro!
> 
> On 4/3/25 05:43 AM, Alessandro Astone wrote:
>> On 30/03/2025 19:18, Alessandro Astone wrote:
>>> Hi,
>>>
>>> I am applying for Ubuntu Contributing Developer.
>>>
>>> Application wiki page: https://wiki.ubuntu.com/aleasto/ 
>>> ContributingDeveloperApplication
>>> Meeting slot:  2025-07-21  16:00
>>> Agenda:  https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
>>>
>>> Thank you,
>>> Alessandro
>>>
>>
>> In light of "Clarifying Policy Re: Asynchronous Contributing Developer 
>> Applications" indicating a preference for asynchronous review, I have 
>> removed myself from the agenda slot I had previously booked and will 
>> be taking questions from the replies to this thread instead.
> 
> Under the "any DMB member can ask for more time" exception, I am 
> extending the final date on this application to April 18th, 2025, due to 
> the unique timing of that communication and your indication.
> 
> Any DMB member, myself included, can push it further if we need to.
> 
>> Please, ask away!
> 
> Sounds good!
> 
> Given my own past experience, my personal standard for reviewing 
> applications involves gauging technical and social skills alike. For 
> more details on the kind of questions I ask, please feel free to read 
> the devel-permissions archives.
> 
> Some reminders:
>   - I'm not asking for perfection, I'm simply asking for your best. Take 
> your time, I don't expect an immediate response.
>   - These questions change from person to person; while it is a great 
> sign of preparedness to read past applications to see what kind of 
> answers I'm looking for, these are unique.
> 
> Something new: I value verbosity. You don't have to write a book, but I 
> would rather you err on the side of over-explaining than under- 
> explaining when unsure. I'll repeat this note in further applications. 
> Again, take your time.
> 
> I'll start with this: your wide range of experience gives me a great 
> initial impression.
> 
> As I'm sure you know, one of the most effective techniques in software 
> engineering is the Rubber Ducky technique[1].

I do believe rubber ducking is incredibly powerful.
Just the other day I was working on a bug (LP: #2105377) which required 
analyzing a debug log from plymouth and cross-checking it with the 
system journal to understand why it was not behaving as expected. So I 
started typing this long, line-by-line analysis of the logs in the 
related Launchpad bug where at least 1 other developer was taking an 
interest. As I was getting towards the end of the analysis it suddenly 
made sense! Quickly wrote a patch and sent a debdiff accompanied by just 
a minimal portion of my previously pages long text :P
So, although my intent was to eventually reach a person and not a duck, 
in the end I could understand the problem by myself just by explaining 
it aloud. Very satisfying!

Sorry, that wasn't a question but as it was so recent I was compelled to 
tell the anecdote.

> A related concept is the 
> "explain it like I'm 5" technique, or ELI5.
> 
> I already know the answer to these questions, but let's pretend you have 
> time-traveled back to the year 2007. I am 5 years old again, and I have 
> kindly asked you to answer some questions for me about the year 2025:
>   - What is LineageOS, what is Android, and what do those things mean 
> for an average phone user? (Read: "30 second elevator pitch.")

"""
Android is the most popular operating system for smartphones. However 
the smartphone manufacturers do not allow you to modify their operating 
system, which is often bloated or tied-down to Google online services. 
LineageOS is a replacement operating system that can be ported to any 
off-the-shelf Android device, it is entirely open source so you can 
assemble it as you prefer, and it is not tied-down to those nasty Google 
online services; your favourite device might already have a port, 
check-out lineageos.org and join our community. If you're a 
developer-type check-out our dev wiki and chatrooms and start hacking 
around!
"""

Now, as a side-note, I actually got hooked to LineageOS just because I'm 
a tinkerer and love to explore and break my stuff. I have no issues 
per-se with using Google online services and what that entails for my 
privacy, but that's the typical pitch instead.

>   - How easy is it to port a phone OS to a new phone, very generally 
> speaking? Is it as easy as some people make it look?

It depends. Nowadays, thanks to a clear and stable separation of 
hardware interfaces and their implementations, you can re-use an Android 
vendor's pre-builts bits (namely the vendor.img and boot.img partitions) 
as-is and boot a LineageOS system in mere minutes. However for 
contributing a port to LineageOS upstream it must be entirely 
source-built (or, as much as possible), taking only a minimal set of 
blobs from the vendor, which takes considerably more effort. At least 
for me. I do not like working with blobs.
I believe HALIUM ports also often use the prebuilt vendor.img but have 
to at least recompile the kernel because systemd or other components 
require some additional features over the standard Android kernel 
requirements.

>   - Are you at all familiar with Lomiri/Ubuntu Touch? What's your opinion?

Yes, as touched on above I am. I own a Volla Phone 22 which has a 
maintained Ubuntu Touch port, which was gifted to me by Volla Systeme 
GmbH with the intent of ensuring compatibility with Waydroid because 
being able to still run Android apps, at native speeds, is a solid 
selling point.
I generally like the Lomiri shell, but I think it could really use a 
rebase on Mir 2.x, which I believe is still WIP. At the same time 
Android or iOS have accustomed us to a level of UX polish that makes it 
impossible for me to consider using it as my daily driver. I believe 
GNOME Shell mobile and the responsive libadwaita applications come 
closer to that level of UX polish, but also not quite... (disclaimer: I 
have not tried that for more than 30 seconds.)

>   - [Bonus question, non-blocking, optional] As a prospective Ubuntu 
> Member talking to a young person interested in the project, how would 
> you encourage them, and/or what advice would you give them?
> 
Join a matrix room, such as a local community or a dev channel, start 
following some discussions and do not be scared to intervene with 
questions or ideas.
I am now personally trying to communicate via Matrix as much as 
possible, as I believe it is the best way to construct a sense of 
community. I especially appreciate when users and developers interact in 
the same room; it keeps us devs-types honest and focused on the mission 
of delivering a product for the users and not just for ourselves.

> Okay, back to 2025. Here are some further questions:
> 
> In your own words, what does it mean to be an Ubuntu Member?
> 

Being an Ubuntu Member means sharing the Ubuntu values, bringing some 
value to the project in any shape or form, and have that being 
recognized by other Ubuntu Members. To me as a developer specifically, 
being an Ubuntu Member means that I share the values of delivering 
stable and timely updates to our stable releases, while on the flip-side 
exciting and fresh updates for the next release, and understanding how 
the project is socially structured to achieve just that.

Being an Ubuntu Member also means representing the project, engaging 
positively with the community and other developers, considering oneself 
accountable for their words and actions.

> Please take some time to reflect on this portion of the Ubuntu Code of 
> Conduct:
>  > When somebody leaves or disengages from the project, we ask that they 
> do so in a way that minimises disruption to the project. They should 
> tell people they are leaving and take the proper steps to ensure that 
> others can pick up where they left off.
> 
> While your experience is wide-ranging, could you please explain the 
> steps you took to gracefully disengage from projects that are firmly in 
> your past?
> 
> I am not attempting to hold any potentially negative history over your 
> head. I am simply trying to gauge your understanding of this clause, 
> separately from your publicly-stated employment at Canonical.
> 

You might have noticed that I am using my personal email address for 
this exchange, and that was intended as a statement of intentions.

> If you must answer this question privately, that is okay, please send me 
> a separate, direct email with the information you are willing to share. 
> I also want to give you the benefit of the doubt, so if I'm even 
> slightly suggesting something that's false, tell me. :)
> 
Yes, I'm not sure where you got the sense that I may have left other 
communities disgruntled or negligently, or even that I left at all...

I obviously don't have as much time as I had as a university student, 
but I'm still an active contributor to Fedora KDE and attend the team's 
weekly voice-meeting, and I'm still an active contributor to the 
upstream KDE project. I believe some people may find that upsetting 
given my current job position, but I am a true open-source enthusiast 
and can only see being involved in multiple different communities as a 
positive.

I am still actively maintaining Waydroid, which being based off of 
LineageOS also means occasionally keeping in touch with that community.

I am not active in LineageOS upstream anymore however, and was removed 
as a device maintainer. I requested to be removed in private chats with 
the respective co-maintainers, as I didn't see myself spending time in 
the near future on continuing to maintain those device ports.
If I were the only maintainer of one device I would have publicly marked 
the device as unmaintained to stop producing official deliverables for 
it until a new maintainer could be found.

I am in very good rapports with everyone I know from those communities. 
I had the opportunity to attend FOSDEM 2025 sponsored by Canonical, 
where I could spend some time not only with my new Ubuntu and GNOME 
friends but also with my Fedora and KDE friends, and share a dinner with 
my LineageOS friends... :)

The biggest shift in engagement has been that I now mostly do stuff over 
the weekend or when pinged, rather than being always present. For 
example, I had pretty much lead the Qt5/KF5 -> Qt6/KF6 transition in 
Fedora KDE and that just wouldn't be possible for me today.
> Okay, enough social questions, on to technical ones.
> 
> When writing a manual test case, what do you consider? Is there any kind 
> of defined process you follow?
> 

When writing a manual test case there are two competing driving factors:
* the will to cover the functionality of the package as extensively as 
possible;
* the feasibility for a user to be able to complete the test case.

Maximizing both factors at the same time is impossible, so we need to 
find some balance.
I try to identify the most popular use-cases for the package and focus 
on a high-level overview of the functionality; the low level stuff will 
generally and hopefully be tested with unit-tests or integration tests 
at build time and/or as autopkgtests.
For a graphical application, that would be generally along the lines of: 
"open the app, navigate to some section of the app and perform some 
operation; repeat for other sections of the app"
Sometimes we need to filter-out test cases that require specific 
hardware, or mark it as optional or otherwise try to simulate it somehow.

If the package can be split into components, the process shall apply to 
each component.

> Pick your favorite FTBFS fix and tell me why it's your favorite. Would 
> you have done anything differently in hindsight?
> 
Ok, my favourite has to be discovering a GCC bug with C++ coroutines... 
I prepared a minimal reproducer (well, as minimal as my understanding of 
C++ coroutines goes which is not that deep) and presented it to the gcc 
maintainers which prompted a quick fix upstream: 
https://bugzilla.redhat.com/show_bug.cgi?id=2342065#c11

Unfortunately that was found in Fedora and not Ubuntu so I'm not sure it 
counts...

My favourite Ubuntu FTBFS then is ubuntu-report as seen just recently 
this cycle. It was not an issue with compiling the program, but rather 
the build-time tests were failing following a tzdata update. It would 
have been caught by autopkgtest as well, but because ubuntu-report does 
not explicitely depend on tzdata that autopkgtest was never run for the 
tzdata migration.

The issue goes like this:
ubuntu-report collects the system's timezone information by reading 
/etc/timezone. However tzdata=2024b-5 stopped generating /etc/timezone 
in favour of just using the standard systemd way to read the timezone, 
which is by following the /etc/localtime symlink.
ubuntu-report includes some tests that run against a mock root 
directory, and those continued to work as they manually populated an 
/etc/timezone file, but also include some integration tests that run 
against the real system, and indeed those failed.
After undertanding the problem and finding some documentation in 
tzdata's debian/NEWS, I sent a patch to ubuntu-report in GitHub and got 
it merged. Unfortunately here I expected the maintainer to upload a new 
release to the archive but I didn't notice that the git branch had some 
changes that wouldn't fly with the Feature Freeze already in place; that 
had to be pointed out by the maintainer who naturally suggested to 
backport the individual patch instead. So, in hindsight I could have 
checked the git history myself and proactively suggested a small 
backport myself instead.

I think this is my favourite because FTBFS failures that generate from 
compilers enforcing newer better standards (C/C++) are generally not 
that interesting... except when you find a compiler bug :)
My university thesis was around compilers and code optimization so I do 
have a soft-spot for compilers anyways...

> I'll admit this is a pointed question: have you done research into 
> whether anyone has proposed improvements to the SRU process like you've 
> stated? If you have not done this research, could you please do so, and/ 
> or ask around[2]?
> 

I have brought up the topic to my team (Canonical's Desktop Team) in 
multiple occasions. I am aware of some conversations aimed in this 
direction, and others not so much.

There is a floating idea in the Desktop Team to start advertising 
-proposed updates of critical desktop components in, for example, 
Discourse to gather users for mass regression-testing campaigns.

I know there is a strong drive from the SRU team to push for properly 
peer-reviewed changes, however I believe that doesn't satisfy me. Peer 
review is required but it is not sufficient. In facts I believe peer 
review is of secondary importance to extensive real-world regression 
testing, when considering that the upload must already come from a 
trusted person, hopefully domain-expert, and reviewed by an SRU team 
member (non-domain-expert, which is the point of pushing for 
peer-review, I understand that)

> Once this is complete, does this change your constructive criticism, 
> and/or are you willing to assist on this front?
> 

On the topic of automated tests, I plan on spending a significant amount 
of time in the near future covering the desktop components in 
OpenQA-style integration tests that actually navigate the desktop 
graphically and performing operations just as a user would with mouse 
and keyboard.

I hope at some point to see this integrated at the same level that 
autopkgtests are today, gating every package promotion.

> One last technical question for the time being: what do you consider 
> when creating a new source package from scratch? Could you give me a 
> taste of your process?
> 

I think the most ergonomic way is to take an existing package that 
follows modern packaging guidelines (that would generally mean 
debhelper-compat=13 today) as an example and start populating the 
debian/ directory while cross-referencing the documentation (e.g.: 
https://canonical-ubuntu-packaging-guide.readthedocs-hosted.com/en/latest/). 
Also, packages living under the same umbrella and being maintained by 
the same team often have a similar "style" or "process" preference, for 
example the Ubuntu Desktop Team prefers the git-buildpackage style with 
pristine-tar, and hosts its packaging in salsa.debian.org; that is 
documented in https://wiki.ubuntu.com/DesktopTeam/Git

An important detail that I also want to mention is the debian/copyright 
file which basically forces one to think accurately about the project 
licensing, which albeit cumbersome is a vital part of a software 
collection project. Ubuntu follows Debian's DFSG guidelines, and a 
project which does not respect those requirements cannot be included in 
Ubuntu, or rather must be limited to the multiverse or restricted 
section where things like the NVIDIA proprietary drivers live.

> [1] https://en.wikipedia.org/wiki/Rubber_duck_debugging
> [2] Hint: if you openly ask this in Ubuntu Development on Matrix without 
> pinging me, I might be the one to answer it for you.
> [2a] Bonus points if you ask around to specific people first, to get 
> general opinions on your feedback.
> [2b] Extra bonus points if you keep all interactions friendly and 
> constructive, and reflect on it in your response.
> [2c] Extra extra bonus points if you reach out to an Ubuntu Developer 
> you have not talked to before.
> [2d] Extra extra extra bonus points if you end up being persuasive 
> enough that the SRU team actually changes policy.
> 
> Have a great weekend,