Contents

  1. Who I am
  2. My Ubuntu story
    1. My involvement
    2. Examples of my work / Things I'm proud of
    3. Areas of work
    4. Things I could do better
  3. Plans for the future
    1. General
    2. What I like least in Ubuntu
  4. Comments
  5. Endorsements
    1. Simon Quigley
    2. Nick Rosbrook
    3. Lukas 'slyon' Märdian
    4. Simon Chopin
    5. TEMPLATE

I, adrien, apply for core-dev.

Name

Adrien Nader

Launchpad Page

https://launchpad.net/~adrien

I am applying because:

I'm applying for Core Dev directly rather than MOTU because most of the uploads I've done contain packages that go in main. As such, MOTU would only unblock me partially and would still use sponsor time.

Who I am

My Ubuntu story

My journey with Ubuntu started with early releases, roughly at the time I was starting to use Linux (always with live systems unfortunately). I cannot directly remember the versions I used but I remember the wallpapers: warty, edgy, hardy (the wallpaper you can't forget!), intrepid. At that point I spent a year or two with opensuse and then several years with Slackware. Ultimately, my taste for tweaking everything in my system weakened and I got annoyed at the development being closed to less than a dozen people. The last straw was finding out several people reported the same issue with fix but without being aware of others as there was (and still is) no bug tracker, only private emails. I was done, I wanted something with actual community involvement.

My involvement

In late 2022, I joined Canonical in the Foundations team to take care of cryptography-related packages which I've enjoyed a lot. Since then I've been aiming at keeping them as up-to-date as possible without introducing instabilities nor hampering long-term (security) maintenance.

Examples of my work / Things I'm proud of

Areas of work

I've been taking care of cryptography-related packages since I joined Canonical in late 2022.

The most notable of these is openssl: a large package with many reverse dependencies, frequent updates which are known to be likely to introduce regressions. Every cycle, I prepare its most recent release we can have in Ubuntu while ensuring stability and the ability to do long-term support, including for security updates.

Another one is gnutls which shares a number of similarities with openssl but on a smaller scale.

For both, there are many language bindings that need to be updated and fixed on a regular basis to match their updates. This has been the case recently with pyopenssl, m2crypto, ruby3.{1,2,3} and nodejs for instance.

To improve cryptography management in Ubuntu in general, I have been working on crypto-config for which the specification was recently released on discourse. The main motives are to centralize and unify how cryptography is configured in Ubuntu, and make it more manageable to disable deprecated algorithms. Extra care has been taken to make it possible to integrate this gradually in the distribution in order to avoid flag days and disruptive transitions. For instance, the changes are already in Oracular's openssl and Plucky's gnutls but are without effect until the opt-in 'crypto-config' package is installed (currently in the NEW queue).

For all these, I interact regularly with the Security and Server teams in addition to Foundations. I also need to pay attention to the schedule of my changes, foresee potential regressions and either prevent or fix them in a timely manner. I take pride in the lack of complaint and issues even though that doesn't sell as well as shiny new things nowadays.

I've also been deeply involved in the armhf 64-bit time_t transition, also known as t64. I worked around the clock to analyze and diff the ABI of thousands of packages. This is a work that had been started collaboratively in Foundations but I then specialized in it. Lacking upload rights, my name isn't written in the transition but I worked with uploaders and maintainers, including in Debian, to answer their questions (for instance about the sources of ABI incompatibilities).

Devel

Various packages

OpenSSL and following up with its changes

Transitions

Autopkgtest retries

I've retried thousands of tests (while being mindful of the queue sizes). These retries were far from being blind and automated. Many times it was for temporary failures but I've also changed triggers to reflect transitions and dependencies or reverse-dependencies. Due to trakcing tests, I've reported infrastructure issues sevral times (I'm not counting).

MIR

SRU

New packages

+1 maintenance

Things I could do better

I heavily dislike short-term fixes. I think I've gotten this from work when having to add work-arounds for releases and at best creating bug tracking entries for actual fixes, and never fixing the actual issues (which were still causing troubles of course). This makes me do fewer changes which require less maintenance over time. I think this is a good match for cryptography-related packages. The downside is that it takes more time upfront and it is impossible to tell in advance whether this will be recouped later on or not. This is a balance that I try to improve and I am very open to feedback about it.

I mentioned changes above but this actually also applies to e-mails for which the balance should tip more towards faster replies.

Plans for the future

General

I've been tracking openssl and gnutls versions pretty closely in the latest releases. I'd like to push that further in the future and track the stable git branches in order to reduce the likelihood of encoutering fixes that introduce behavior changes after the release.

I also want to make more packages take advantage of crypto-config and ship corresponding profiles. Being core dev will be very helpful here but I will also always discuss the changes with the usual maintainers of the packages first.

What I like least in Ubuntu

I feel like the tooling situation is unsatisfactory. There are several repositories of tools with sometimes overlapping functionalities. Most often, the documentation is succinct and not discoverable. I am also confident that almost any time spent on tooling is recouped within weeks or a few months at most.

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.

Simon Quigley

At the time of writing, I have sponsored nine uploads for Adrien:

Package

Version

Bugs

Action

Notes

gnutls28

3.8.1-4ubuntu4

python-googleapi

2.131.0-0ubuntu1

upgrade

cinder

2:24.0.0-0ubuntu2

rust-libgit2-sys

0.17.0-1build1

rebuild

gnupg2

2.4.4-2ubuntu22

dojo

1.17.2+dfsg1-2.1build1

rebuild

iptables

1.8.11-2ubuntu1

2096615

kakoune

2024.05.18-2ubuntu1

openssl

3.4.1-1ubuntu1

2058017 2073991 2087955 2096810

This is not enough uploads for a fully-qualified technical endorsement of the application. That being said, he has become a familiar face around the Ubuntu Development community, and I generally find his uploads to be high-quality. Working with Adrien frequently enough, I would like to see him become an Ubuntu Core Developer.

While this is not a full and complete endorsement of Adrien Nader's application for Ubuntu Core Developer, I, Simon Quigley, believe we should unblock him in his efforts, and grant Ubuntu Core Developer permissions, immediately.

-- tsimonq2 2025-02-15 16:31:13

Nick Rosbrook

General feedback

I have sponsored several packages[1] for Adrien, and I always appreciate how well-prepared the uploads are. Adrien's MPs always detail the rationale for the change and include PPA builds and autopkgtest results. When changes are requested, Adrien is always engaging and prompt.

Adrien's uploads are indicative of a careful and thorough engineer, and this gives me confidence in granting Adrien Core Developer privileges.

[1] https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=Nick+Rosbrook&sponsor_search=name&sponsoree=Adrien+Nader&sponsoree_search=name

Specific Experiences of working together

I work on the Foundations team at Canonical with Adrien. I have been impressed with his work on openssl, and on cryptography-related packages in general. I also observed the immense amount of time and effort Adrien put into the time_t transition, and it is not an exaggeration to say the transition would not have happened without him.

Areas of Improvement

Adrien often points out aspects of our tooling and processes that could be improved. In at least one instance[2], he actually implemented a prototype and shared it on ubuntu-devel. I think Adrien has a lot of good ideas in this space that the community would benefit from, and I would like to see him collaborate with the community more to land these improvements.

[2] https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2024-June/019712.html

-- enr0n 2025-02-27 15:10:40

Lukas 'slyon' Märdian

General feedback

I have only sponsored 2 packages for Adrien, so far. So I don't feel like I can put a full endorsement.

Specific Experiences of working together

I worked with Adrien during the MIR process of libtracefs, where he picked up and finished the remaining work of adding autopkgtests. Failures on ppc64el and s390x were accepted and tracked as follow-up items, which Adrien picked up and fixed in Plucky or raised with the upstream developers.

Also, on the earlier MIR for libstring-license-perl I coordinated with Adrien and he showed good insights into the case of this Perl package being split out of licensecheck.

Finally, Adrien was of tremendous help when we were running the 64-bit time_t ABI transition in Ubuntu and Debian. Adried did do the deep and recurring ABI analysis, which we based all our work on. He was very quick and dedicated whenever I (or others) had a request to re-analyze a specific edge case after deploying a fix. He was pulling the strings in the background in a way that was very helpful to all Ubuntu and Debian developers involved in this transition.

Areas of Improvement

There are always new things to learn in Ubuntu. With new powers comes new responsibilities, so Adrien should learn about dput[-ng] and additional helpers, such as https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers/tree/cpaelzer/.dput.d/ that can help avoiding simple oversights before uploading a package.

With the limited exposure I have to Adrien's work, I still think he's ready for Core-Dev.

-- slyon 2025-03-03 11:43:02

Simon Chopin

General feedback

I have worked with Adrien for a few years as part of the Foundations team. While we often discuss various packaging topics together, most of our interactions are about OpenSSL, as he took over the responsibility for that package from me. He was also instrumental in the time_t transition as his work on package analysis cut down drastically the amount of manual labor involved, which is saying something considering how much work we still had to do!

I believe him to be ready for Core Dev.

Specific Experiences of working together

Most of our observable work together are openssl sponsorship, e.g. https://launchpad.net/ubuntu/+source/openssl/3.4.0-1ubuntu1.

As far as examples of things that could have been handled better, an example that comes to mind is his [first attempt at SRUing openssl](https://launchpad.net/ubuntu/+source/openssl/3.0.2-0ubuntu1.13), which in its original form included a [change to BlowFish default configuration](https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1990216). While things worked out in the end, it took quite a bit of convincing to get him to see how that would be an unsuitable change for a stable release.

Areas of Improvement

I guess Adrien could improve on his slight tendency to act before identifying the stakeholders, although I think we're all sometimes guilty of that.

-- schopin 2025-03-03 14:45:35

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

CategoryCoreDevApplication

adrien/CoreDevApplication (last edited 2025-03-03 14:45:35 by schopin)