Tim Andersson - Contributing Developer Application

[Simon Quigley]

Hi Tim!

Thank you for your thorough response. I am quite satisfied with your answers, so I am happy to say that my vote is now a firm +1.

Responses inline.

On 3/31/25 04:49 AM, Tim Andersson wrote:
> 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

“Shoot for the moon. Even if you miss, you'll land among the stars.”
  -Norman Vincent Peale(?)

> ## Commits
> 
> ### britney
> 
> #### https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?id=522adc7f7c6356d1d677853978c76bb6f3a02433 <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.

Great! From all available information, it seems like you collaborated with the subject-matter experts and delivered a high-impact fix. Thank you for your work!

> ### autopkgtest-cloud
> 
> #### https://git.launchpad.net/autopkgtest-cloud/commit/?id=87f9a323cc945375b6c04d931c813e14fe7b12ef <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.

Yeah, in my opinion LPCI is definitely familiar but unique! Honestly, I wish more people knew about it and used it.

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

I'm glad you can be in honest, good spirits about a past mistake, this is definitely one of the factors in my +1.

The vast majority of even Core Developers can point to at least one similar mistake they made. The important thing is setting aside the embarrassment, perhaps chuckling to yourself for a quick second, then fixing it productively.

"we prefer to err, learn, and err less in future than to postpone action indefinitely"
  -Ubuntu Code of Conduct 2.0

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

Fully agreed; thank you for your work here!

> #### https://git.launchpad.net/autopkgtest-cloud/commit/?id=bc98541daa133ed90b3648740f110cdc434982ce <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?

"I'll allow it." I'm still curious, though.

> #### https://git.launchpad.net/autopkgtest-cloud/commit/?id=63598c9967339b5a724a49a68c9a5375e41ca2d3 <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.

Mega slow... megaslow... megapi- nevermind. (If you know, you know, if you don't, you don't.) ;)

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

This is another factor contributing to my +1.

"This bug/issue piques my interest because it will allow me to learn something new and that is good" is *such* a great attitude to have. I would encourage you not to lose it, *that's* what will get you to Core Developer. :)

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

Great, thank you for your work!

> ### ubuntu-release-upgrader
> 
> #### https://git.launchpad.net/ubuntu-release-upgrader/commit/?id=6b21b56970db27db15bd73e691a70c66b51c35a7 <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!

Not everyone remembers every single patch they do off the top of their head, this is quite okay. ;)

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

This issue specifically is probably something that could still use another pass to make it more robust, in my personal opinion.

In fact, in one of the bugs I've been working on in between responding to these emails originally had a red herring due to a very related issue. Take a peek at the recent Ubuntu Development Matrix scrollback. :)

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

Ooh, this is genuinely one of my favorite parts of the stack. Thank you for your work!

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

We like making Jenkins jobs green!

> ## 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!

Thank you so much for sharing this! I am quite happy you chose to answer this question for yourself.

I can certainly relate; while I do not have professional embedded experience, I do have some (past and pending, not current) professional experience hacking on OpenEMR, which might be interesting for you: https://github.com/openemr/openemr

(There are a handful of fixes we either have previously drafted to send upstream or patched in production, including an Ansible-based testing suite I wrote.)
(Extra credit, with the help of a publicly-anonymous colleague: https://docs.minddripmedia.com/how-to/update-icd10/ )

I would definitely be curious to hear more about your past experience, either in person at Ubuntu Summit or async via Matrix. :)

> ## Conclusion
> 
> Thanks very much for responding, and I'm sorry if my response is quite long!
> 
> Happy Monday, and have a lovely week.

Have a great weekend, Tim! I wish you all the best, and if there is anything I can do to help, please let me know!

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/devel-permissions/attachments/20250404/68dfdd5c/attachment-0001.sig>