CoreDevApplication

I, adrien, apply for core-dev.

Name

Adrien Nader

Launchpad Page

https://launchpad.net/~adrien

I am applying 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 pay back all the review time I've benefited from.
  • I'd like to help people who seek sponsorship.
  • I'd like to also help with transitions.

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

  • anacron_2.3-33ubuntu2

    • This SRU involved detailed work as can be seen in https://launchpad.net/bugs/2006589 . There was only a single path to prevent the issue (which was that upgrading from 2.3-33 would disable the service). The SRU was therefore about using that single chance at a fix. It took a fair amount of testing and a few iterations which makes following through the comments sometimes difficult (and similarly, Steve reviewed a deleted patch in #23)

  • openssl_3.0.2-0ubuntu1.13

    • This was originally an SRU for four issues. Eventually, I figured out that fixing one of them would result in a behaviour change, just like the issue had introduced one. I followed the SRU rules and dropped it (behaviour changes in openssl, especially for fixes, are multi-faceted and therefore tricky; we can discuss that if you want). The SRU is also interesting as it includes patches to fix serious performance degradation which effectively prevented some workloads from running at all. I've also learnt that it's probably wiser to do smaller SRUs for openssl and maybe have them staged which security updates which occur regularly enough anyway.

New packages

  • python-google-api-core_2.19.0-0ubuntu1

    • pyopenssl has been deprecating functions that are implemented in pyca/cryptography and then dropping these functions. This has been putting pressure on reverse-dependencies, including python-oauth2client which had been deprecated upstream, and in turn on its reverse-dependencies. An update to python-googleapi was needed, and this package was a dependency. I'm a bit sad that I've been lacking time to do more on this package debian side unfortunately but at least it has allowed almost everything to move on.

  • crypto-config_0.7.3-0ubuntu1: https://bugs.launchpad.net/ubuntu/+bug/2098879 (to be uploaded soon)

+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:

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)