Allgemein

Isoken Ibizugbe: Everybody Struggles

Von [email protected] Loading...
Isoken Ibizugbe: Everybody Struggles

That’s right: everyone struggles. You could be working on a project only to find a mountain of new things to learn, or your code might keep failing until you start to doubt yourself. I feel like that sometimes, wondering if I’m good enough. But in those moments, I whisper to myself: “You don’t know it yet; once you do, it will get easy.”

While contributing to the Debian openQA project, there was so much to learn, from understanding what Debian actually is to learning the various installation methods and image types. I then had to tackle the installation and usage of openQA itself. I am incredibly grateful for the installation guideprovided by Roland Clobus and the documentation on writing code for openQA.

Overcoming Technical Hurdles

Even with amazing guides, I hit major roadblocks. Initially, I was using Windows with VirtualBox, but openQA couldn’t seem to run the tests properly. Despite my mentors (Roland and Phil) suggesting alternatives, the issues persisted. I actually installed openQA twice on VirtualBox and realized that if you miss even one small step in the installation, it becomes very difficult to move forward. Eventually, I took the big step and dual-booted my machine to Linux. Even then, the challenges didn’t stop. My openQA Virtual Machine (VM) ran out of allocated space and froze, halting my testing. I reached out on the IRC chat and received the help I needed to get back on track.

My Research Line-up

When I’m struggling for information, I follow my go-to first step for research, followed by other alternatives:

  1. Google: This is my first stop. It helped me navigate the switch to a Linux OS and troubleshoot KVM connection issues for the VM. Whether it’s an Ubuntu forum or a technical blog, I skim through until I find what can help.
  2. The “Upstream” Documentation: If Google doesn’t have the answer, I go straight to the official openQA documentation. This is a goldmine. It explains functions, how to use them, and lists usable test variables.
  3. The Debian openQA UI: While working on the apps_startstop tests, I look at previous similar tests on openqa.debian.net/tests. I checked the “Settings” tab to see exactly what variables were used and how the test was configured.
  1. Salsa (Debian’s GitLab): I reference the Salsa Debian openQA README and the developer guides sometimes; Getting started, Developer docs on how to write tests

I also had to learn the basics of the Perl programming language during the four-week contribution stage. While we don’t need to be Perl experts, I found it essential to understand the logic so I can explain my work to others.

I’ve spent a lot of time studying the codebase, which is time-consuming but incredibly valuable. For example, my apps_startstop test command originally used a long list of applications via ENTRYPOINT. I began to wonder if there was a more efficient way. With Roland’s guidance, I explored the main.pm file. This helped me understand how the apps_startstop function works and how it calls variables. I also noticed there are utility functions that are called in tests. I also check them and try to understand their function, so I know if I need them or not.

I know I still have a lot to learn, and yes, the doubt still creeps in sometimes. But I am encouraged by the support of my mentors and the fact that they believe in my ability to contribute to this project.
If you’re struggling too, just remember: you don’t know it yet; once you do, it will get easy.