Tim Andersson - Contributing Developer Application

Mon Mar 31 09:49:20 UTC 2025

Hi Simon,

# Begin

Thanks for the response and no worries for the delay, I obviously
understand the cause ;)

>  In your own words, what does it mean to be an Ubuntu Member?

For me, it means I'm a recognised member of the Ubuntu community. It also
means people hopefully see patches and work with my name on it and expect a
degree of quality :) it's also a step on my path to core dev, later down
the line. I'm committed to this community and project and I want the badge
to say so :P

## Commits

### britney

####
https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?id=522adc7f7c6356d1d677853978c76bb6f3a02433

> How were you made aware of the issue, or what piqued your interest about
it in particular, and did you collaborate on it?

This was made aware to me through a card created by vorlon, and brought to
my attention by bdmurray. It was a great thing to work on as we were
queueing a colossal amount of unnecessary i386 tests; hence why it was
interesting. I collaborated mostly with Brian on it, but mostly worked
alone.

> Did you initially take a different approach to your solution, and if so,
could you briefly walk through your thought process here?

Well, no, not really. Initially I was wrapping things in a try/except as I
wasn't sure if I was accessing the variable I so desired; it'd be easy for
me to say that if I were to do this again, I'd run britney locally or try
to run the tests or at least try and test it locally in some manner. But
britney is a behemoth so I'm not sure I would do that! I don't like the git
history associated with this change, but I won't lose sleep over it.

> What was the end result, what kind of impact did it make, and in
hindsight, would you have done anything differently?

The end result is we're wasting far, far less compute on unnecessary i386
testing. Prior to these few changes, over 80% of the i386 tests we were
running in production were useless; which drastically affected our amd64
throughput, as the runners are the same.

### autopkgtest-cloud

####
https://git.launchpad.net/autopkgtest-cloud/commit/?id=87f9a323cc945375b6c04d931c813e14fe7b12ef

> How were you made aware of the issue, or what piqued your interest about
it in particular, and did you collaborate on it?

I'm not really sure there was an issue persay here, well, I guess, lack of
CI on autopkgtest-cloud was indeed an issue hehehe. Anyway, this was soon
after I'd joined the company, and I was familiar with setting up CI
pipelines so this was a great starter task. What was particularly
interesting, was learning LPCI as opposed to Salsa or github CI pipelines.

> Did you initially take a different approach to your solution, and if so,
could you briefly walk through your thought process here?

Yeah, that script to do the linting was absolutely insane, I have no idea
what I was doing there. In hindsight, I'd obviously NOT write a custom
script to find files of a specific type lol!

> What was the end result, what kind of impact did it make, and in
hindsight, would you have done anything differently?

The end result was we actually had some CI for autopkgtest-cloud! Yippee!
At the time, the project was in *somewhat* of a maintenance mode, and
laterally became more actively developed; so the CI was a good precursor to
regular development.

####
https://git.launchpad.net/autopkgtest-cloud/commit/?id=bc98541daa133ed90b3648740f110cdc434982ce

> How were you made aware of the issue, or what piqued your interest about
it in particular, and did you collaborate on it?

> Did you initially take a different approach to your solution, and if so,
could you briefly walk through your thought process here?

> What was the end result, what kind of impact did it make, and in
hindsight, would you have done anything differently?

####
https://git.launchpad.net/autopkgtest-cloud/commit/?id=63598c9967339b5a724a49a68c9a5375e41ca2d3

> How were you made aware of the issue, or what piqued your interest about
it in particular, and did you collaborate on it?

The update-github-jobs script was mega slow, and we kept getting pinged
about it on IRC by bluca I believe.

What piqued my interest was the opportunity to learn the python-swiftclient
library. I did not really collaborate on this outside of MP reviews.

> Did you initially take a different approach to your solution, and if so,
could you briefly walk through your thought process here?

The script was initially hitting an external URL which in itself had a
redirect, and was doing so with urllib, so you can imagine how this'd
affect the performance. Using swiftclient and fetching results directly
from swift improved the performance a drastic amount, and simplified the
code too.

I did not initially take a different approach.

> What was the end result, what kind of impact did it make, and in
hindsight, would you have done anything differently?

The script became more reliable, faster, and simpler to read. I don't think
there's anything I would've done differently.

### ubuntu-release-upgrader

####
https://git.launchpad.net/ubuntu-release-upgrader/commit/?id=6b21b56970db27db15bd73e691a70c66b51c35a7

> How were you made aware of the issue, or what piqued your interest about
it in particular, and did you collaborate on it?

Disclaimer; truth be told, I don't recollect this fix all that well hehe!

In the URM team, we have automated upgrade testing; I imagine an upgrade
started failing, and I was looking into this issue. I collaborated with
enr0n about this a little bit, as well as bdmurray. It was a very
interesting issue, but also quite frustrating I imagine hehe.

> Did you initially take a different approach to your solution, and if so,
could you briefly walk through your thought process here?

Well, there wasn't much of a thought process from what I remember; the
problem itself was mostly just digging to try and figure out exactly why
these variables weren't set - a familiar issue right now, since I recently
worked on https://bugs.launchpad.net/auto-package-testing/+bug/2103695.

I probably took a similar approach as I did in the bug mentioned above;
digging into different ways to get into the root shell, trying to replicate
the somewhat-odd setup we have for our upgrade testing. u-r-u changes the
font but must first figure out how the user got root privileges; in our
upgrade testing, we get those root privileges in a way that does not allow
the font to be changed, since we run the upgrader in noninteractive mode.

> What was the end result, what kind of impact did it make, and in
hindsight, would you have done anything differently?

Stopped the upgrader tracebacking, and making the jenkins jobs green again.

## A question for myself

### How has your idea of quality changed since joining Canonical and
working directly on, and not with, Ubuntu?

Woah, tough one. Thanks for the question, Tim! ;D

Man, honestly, quality is an entirely different word to me now. The level
of detail and technical proficiency I've been witness to since being
involved with all of this is astronomical. Prior to this, I was working on
scrappier projects; an in-development surgical robot (in academia), and as
an operations engineer in a factory with mobile robots. You can imagine in
these projects, some corners were cut at times.

Since I've been here, I've developed a habit of never writing code I don't
understand. In the past, due to perhaps time constraints or, let's face it,
being a worse engineer (:D), I would take things for granted a lot of the
time. Assuming things worked a certain way, and employing the use of tools
and libraries I don't entirely understand.

This simply doesn't cut it in the Ubuntu ecosystem. I think I've become
like 10 or 20 times the engineer I was before I joined here. I have so much
more confidence in my work nowadays (not 100% yet, though).

QA is in every step of what I do :) Admittedly, I still have tendencies to
be scrappy, or a bit hacky at times. A habit gained from working on mobile
robots in a factory, where quick hacks were often quintessential to getting
things done on time. A habit I'm trying to squash!

## Conclusion

Thanks very much for responding, and I'm sorry if my response is quite long!

Happy Monday, and have a lovely week.
Regards,
Tim Andersson

On Fri, Mar 28, 2025 at 1:17 AM Simon Quigley <simon at tsimonq2.net> wrote:

> Hi Tim!
>
> On 3/19/25 10:32 AM, Tim Andersson wrote:
> > Hi!
>
> Sorry for the delay... Beta. ;)
>
> > I'm applying to be a Contributing Developer.
> >
> > Wiki Page: https://wiki.ubuntu.com/TimAndersson/DeveloperApplication <
> https://wiki.ubuntu.com/TimAndersson/DeveloperApplication>
> > Date: 2025-06-09
> > Time: 19:00
> > Agenda: https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda <
> https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda>
> >
> > I'm wondering however if we could perhaps do this meeting
> asynchronously? I know there's precedent to do this in the past, hehe.
>
> +1 on reviewing via email.
>
> If you've read the recent precedent for this, you probably also know that
> I'm about to ask a mix of social and technical questions.
>
> Please take your time on a response; I'm not asking for perfection, just
> your best.
>
> As opposed to some of the previous applications you may have read, this
> one is going to be much more free-form. I balanced asking for more details
> than usual with being looser on the pedanticism.
>
> In your own words, what does it mean to be an Ubuntu Member?
>
> I've cherry-picked a handful of merge proposals and commits from your
> application. For each one, please briefly explain:
>   - How were you made aware of the issue, or what piqued your interest
> about it in particular, and did you collaborate on it?
>   - Did you initially take a different approach to your solution, and if
> so, could you briefly walk through your thought process here?
>   - What was the end result, what kind of impact did it make, and in
> hindsight, would you have done anything differently?
>
> You don't have to answer all three questions for every single point, you
> can select a mix of each depending on what feels right, but for at least
> one, I'd like to see all three.
>
> Bonus points for a well-articulated story as opposed to rigid answers; I'm
> simply asking you to paint a picture.
>
>
> https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?id=522adc7f7c6356d1d677853978c76bb6f3a02433
>
> https://git.launchpad.net/autopkgtest-cloud/commit/?id=87f9a323cc945375b6c04d931c813e14fe7b12ef
>
> https://git.launchpad.net/autopkgtest-cloud/commit/?id=bc98541daa133ed90b3648740f110cdc434982ce
>
> https://git.launchpad.net/ubuntu-release-upgrader/commit/?id=6b21b56970db27db15bd73e691a70c66b51c35a7
>
> https://git.launchpad.net/autopkgtest-cloud/commit/?id=63598c9967339b5a724a49a68c9a5375e41ca2d3
>
> And finally, make up a question of your own, and answer it how you see
> fit. It could be very easy, or very hard. I'm intentionally leaving this
> one wide open. (And if it's a top-tier question, I just might use it myself
> in the future.)
>
> Warm regards,
> --
> Simon Quigley
> simon at tsimonq2.net
> @tsimonq2:ubuntu.com on Matrix
> tsimonq2 on LiberaChat and OFTC
> 5C7A BEA2 0F86 3045 9CC8
> C8B5 E27F 2CF8 458C 2FA4
>

-- 
[image: Canonical-20th-anniversary]
*Tim Andersson*

Software Engineer (Canonical Ubuntu Release Management)

Email:

tim.andersson at canonical.com

Location:

United Kingdom

canonical.com

ubuntu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/devel-permissions/attachments/20250331/7f66490e/attachment-0001.html>