I, Tim Andersson, am applying to become an Ubuntu Contributing Developer.

I am applying because:

• I want to become an Ubuntu Contributing Developer as part of my journey to MOTU and eventually core dev These long term goals are sub-goals of the main goal, which is to become an official release team member.

Who I am

Hello! My name’s Tim Andersson. I’m a Canonical employee for about 23 months now, in the Ubuntu Release Management Team (fka Canonical Ubuntu QA Team).

My journey with Ubuntu started in something like 2020 (time is a blur sometimes). I was doing my masters degree in Robotics at the time. We were using bionic and ros (Robotic Operating System, for those who don’t know).

This was my first ever usage of a Unix system. One of the first things I did, early on in the masters course, after getting irritated by having to write sudo all the time, was changing the ownership of my / partition. Lesson learnt. Reviving my machine only sparked my interest more!

Since then, I’ve used Ubuntu for every piece of development since. I worked in a factory with mobile robots for a little while, all running bionic, and then after that I was working in a company developing surgical robots, also using Ubuntu. Since that surgical robotics job, I've been at Canonical in the URM/QA team. We handle things around releases, autopkgtest, iso testing and other forms of QA, among other things.

My Ubuntu story

I detailed my early Ubuntu story above, but since I've joined Canonical, I've had a large focus on automated testing, learning a lot about things like OpenQA and other similar tools. On top of this, I have worked with test-observer, integrating ISO test results. I have also done +1 maintenance, upstream bugfixes, etc etc etc. I'll detail this more in the section below :)

My involvement

Examples of my work / Things I'm proud of

- Attending each release sprint in London with the release team - isotesting and small release tasks such as validating torrents

- Whilst I'm not officially a release team member, the URM team is very involved in the release process, and serves to assist the release team during these periods. I have helped with many release related tasks (even if the task is just to ping someone to do something, hehe), and I will be driving the checklist for 24.04.3. I've been reviewing FFe's recently, too.

- Attended MiniDebConf in Cambridge

- Fixing bugs and fighting fires for upstream stakeholders of autopkgtest.ubuntu.com

- Added timestamps to autopkgtest logfiles

- Introduced a CI pipeline for autopkgtest-cloud with linting, charm building, and the like. The commit here doesn't denote the latter, but this was the start

- automated the building of the `autopkgtest-cloud` documentation

- re-designing the mechanism which writes results to our database, which stopped incessant database is locked errors

- Introduced uuid's for each individual test - the commits before and after this one show the full feature

- Added api keys for autopkgtest-web so recurrent users can bypass SSO

- Made the retry button take into account all-proposed

- Added a duplicate check when requesting tests via the webpage as to disallow users to queue the same thing twice - did the same thing for upstream github jobs

- stopped the long standing issue of permanently looping tests - commit

- added a user specific page - viewable here with your launchpad username: https://autopkgtest.ubuntu.com/user/<your-username>/

- fixed an issue which caused new dependencies to not get installed in prod

- minor bugfixes and reliability/performance improvements such as this and this and this and this and this

- added an admin page which at the time helped us identify tests using up too many resources or failing in obscure ways

- started backing up our database

- fixed an issue with ppa testing introduced by noble

- fixes related to incorrect metric reporting such as this

- fix for testbeds that wouldn't get killed when the test was killed

- made a script for monitoring our apache2 requests - now visualised in grafana

- QoL fix restarting services on a charm update

- Making network names flexible to make migrating to new datacentres easier

You can see my full list of commits on this repo here

- Fixed an issue with the content-length header of our db by making britney check the checksum instead

- Fixed an issue wherein britney was queue-ing countless useless i386 tests, which was heavily eating into our amd64 capacity at autopkgtest.ubuntu.com

- I've also responded to pings r.e. security-britney and regular britney

- Introducing pre-commit and LPCI for meta-release

- Updating meta-release for oracular

- I automated one small step of the release process :slight_smile: a torrent checking script

- I have an MP open right now which adds a script for parsing britney logs

- Recently added a script for generating a master diff between iso manifests for all images between point releases. It's ad-hoc and hacky but helpful and should save a fair bit of time each point release

- I've done a lot of requeue-ing of autopkgtests with different triggers etc in an effort to get the tests to pass

- Recently force-badtest'd python-oauth2client - the package is being deprecated and is blocking other packages from migrating

- Made a bug to remove python-certbot-dns-google from the archive for oracular - due to issues with python-oauth2client

- Recently made an MR fixing a failing autopkgtest in media-types, and then made a follow up MR to add the first autopkgtest to media-types to catch the issue fixed by the first MR faster

LPCI isn't a core part of my role, but I'm working on it for fun

- Currently working on an MP adding deb822 support to lpci

- Have an MP open which fixes a bug

I work regularly on auto-upgrade-testing, monitoring the jobs with my team, as well as reproducing any reported upgrade related bugs on my test laptop

- Hundreds of desktop installer tests

- isotracker maintenance (iso.qa.ubuntu.com) - updating testcases and suites and liaising with flavor leads etc

- Currently working on a new greenfield project which automates installer testing on hardware we have in a lab - I wrote all of the scripts and jenkins jobs surrounding the testing. These tests are hooked up to test-observer, for nice viewing of the results. This has been a large portion of my work for the last couple of cycles.

- Wrote openqa tests for the desktop installer also - we should have an openqa instance in the future so I wrote a suite of tests in preparation

- I also attend monthly meetings with members of the openqa community from various distros - you can see info on this monthly meeting here

- Added CI to ubuntu-cdimage

- Added some retries to an important call. Prior to this, if this call failed, the whole image build run would fail, needlessly.

- Some work to enable a new subarch for riscv

- general maintenance things like making cdimage aware of the new devel release codename

- fixed a bug in the upgrader

Areas of work

Let us know what you worked on, with which development teams / developers with whom you cooperated and how it worked out.

- autopkgtest

- britney (security and regular)

- cdimage

- autopkgtest-cloud

- isotracker

- iso testing (automated and manual)

- testflinger

- test-observer

- community interaction on behalf of the release team

- the release process - helping to automate away parts where I can

- QA and image automation/promotion etc

Things I could do better

- Attention to detail - sometimes I have a bit of a tendency to rush aspects of my work (ADHD is fun!) - I should spend more time working directly on distro work, rather than automated testing - something I plan to do for the rest of this cycle and next cycle - Be more present on IRC/matrix - I'm always online but sometimes get so wrapped up in my current task I forget to check for a little while!

Plans for the future

General

- As aforementioned, distro work in general. Next cycle I will start +1 maintenance shifts. I plan to pick up more FFe's, work on seed changes, MIRs, and perhaps even pick up some merges.

- Something I've had my eyes set on recently, is to help out with maintenance and development of LPCI. I've started this work recently - autopkgtest-cloud and other projects I work on utilise LPCI, and it's very widely used around the entirety of Launchpad. I hope to become an active contributor in the near future - I've spoke with some maintainers of the project and my next steps are to start solving any bugs that have been left unattended. I was doing this actively a couple of months ago, when I had some more free time, and I plan to pick this up again soon.

- I'd like to contribute in some way to OpenQA. I attend talks most months, with members from all around the OSS community that utilise and employ OpenQA in some way. The talk is monthly and I'll continue to attend, and hopefully apply the insight garnered from these talks to our own OpenQA instance for Ubuntu. My hope is that as I get more familiar with OpenQA, and use it regularly, I'll become competent enough with it to become an active contributor.

- I'd like to start doing more +1 maintenance for the desktop and foundations teams. I've done a bit in the past, but not enough.

- Smooth out the release process wherever I can - even just small scripts to make tedious steps faster is a bonus!

- Further refactoring and improvement for autopkgtest-cloud - a lot of work has been done in the last year, however, there's still a lot left to do!

What I like least in Ubuntu

- Lack of documentation! I'm sure this is a common enough complaint, hehe.

- The release process is somewhat, currently, quite manual. It's clunky, and whilst there's obviously valid, historical reasons for this, we can improve it if we put our minds to it!

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

Florent 'Skia' Jacquet

While I'm not directly sponsoring package uploads for Tim, I've been working with him for the past year and a half, and I can say for sure that his work has definitely helped make Ubuntu better. From manual ISO testing to integrating more and more fully automated testing in our Jenkins, this alone would justify his application. That goes along with the autopkgtest work, where we often review each other, and all the other tiny bits of infra where we work together. Looking forward to seeing more of what he'll bring to UI and desktop testing!

-- hyask 2025-03-13 16:05:18

Julian Andres Klode

I have not sponsored packages for Tim and I don't think he did many "uploads" but I do believe that his work on all the testing infrastructure should qualify him for the status of contributing developer as well, because focusing solely on packages would do disservice to other worthwhile technical contributions like his.

-- juliank 2025-03-15 13:52:01

Paride Legovini

General Feedback

I am familiar with Tim's work since the beginning of his Ubuntu journey within Canonical, and I believe he is more that ready to become an Ubuntu member and contributing developer. More specifically Tim actively participated to several key areas of Ubuntu development: he is an active maintainer of the autopkgtest service, participated to several Ubuntu release sprints, actively engaged in ISO testing activities (performing tests, expanding the test cases, and administering the ISO tracker). He is active in the main Ubuntu communication venues (Matrix, IRC, mailing lists, discourse), always willing to help fellow Ubuntu developers, flavor developers and community members in general. He fully deserves to be an Ubuntu Developer.

The links provided in the application support all the above, and show how Tim's contributions are technical, so I specifically support the "contributing developer" status.

Areas of Improvements

Tim's focus on QA, CI and release processed didn't naturally brought him to do many package uploads. I suggest him focusing on this area, working towards MOTU membership, as Tim himself outlines in the applicaiton.

-- paride 2025-03-16 18:55:01

Endorsements

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

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

CategoryUniverseContributorApplication