I, Arif Ali, apply for upload rights for package sos and sosreport.

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.

Who I am

I am Arif Ali, a Staff Support Engineer at Canonical's supporting a specific customer, I work on sosreport at work as well as my spare time. I have a BS in Computer Science and Mathematics as well as a MSC in Advanced topics in Computer Science.

Before joining Canonical in 2019, I worked in the HPC industry deploying, architect, designing and supporting systems across many industries including Motorsport, Aerospace, Automotive and Research.

I have been using Linux since 1999 with various distributions, with the earliest being Mandrake Linux, with Fedora Core 1 being the first official distro for work Laptop in 2003. Which you can imagine had several issues to actually get working. Over the years I delved into Debian, CentOS, Red Hat and Ubuntu, interchanging based on experiences and requirements.

My Ubuntu story

I started using the first Ubuntu releases, and interchangeably used many of the distributions and versions. Since working with Linux, I have always found that ubuntu is one of the distros that works more easily with many more items integrated to ensure it works from the initial install.

Since joining Canonical, my primary OS has been Ubuntu, and also converted all my Servers, VMs and containers from whole range of Linux OSs to Ubuntu, and all my environments are now solely Ubuntu based.

At the same time, I'm a total open-source advocate, so like to promote Ubuntu/Linux to my family and friends; so much so that my parents use 12.04 on their desktop.

One thing I can improve on, is help promote Ubuntu more on social media and help people to understand the whole ethos of Ubuntu LTS and see how we can close the gap of understanding the support structure that is in place for Ubuntu supported platforms.

My involvement

Examples of my work / Things I'm proud of

Below you can see the sponsorships for the work I have done since May 2024

• Ubuntu Sponorships

• sosreport Debian Sponsorships

• sos Debian Sponsorships

The things I am proud of with sos project:

• I have been contributing to upstream sos since I joined Canonical

• Got much more involved since April 2023 and made significant improvements

• In December 2023 I was added as one of the maintainers of the project Discussion #3466

• Due to significant issues with 4.7.0 SRU LP #2054395, I helped revamping the CI for sos, and we now do more CI for ubuntu than Redhat.

• Added various functional testing based on issues we have faced in Ubuntu.

• Added non-voting testing for latest dev releases to that we catch issues before any SRU takes place. PR #3587

• Took over as maintainer of sos in Debian in July 2024 which is now being auto-synced to Ubuntu Bug #1076347 & Bug #1076253

• Renamed the package in Debian, which flowed through to Ubuntu. This involved various stages
  • Building the updated debian folder and being sponsored into NEW
  • The package arriving into unstable, this caused issues as I had already uploaded the old package with the same version; this inadvertently caused build failures across britney for Debian, and then Ubuntu after the auto-sync. This meant that I had to upload a new package with a new version to solve this issue.

  • For Ubuntu, we had 2 further issues wrt migration. The package was pointing to sosreport as well and trying to run autopkgtest, but these were failing. The new package also arrived in universe which meant we couldn't depend on the universe package from the transitional package. New bug was created LP #2097740 to handle the src:sosreport package removal as well as promoting sos to main. I then pinged the ubuntu-archive team on Matrix who were able to take on the work as required.

  • The ubuntu seeds was changed for plucky so that new distros will install sos by default instead ot sosreport, this mean that the sosreport package has ended up in universe

  • On the Debian side, worked with a DD to add a hint for migration, which worked. This also automatically removed sosreport from testing

  • Jeremy Bicha also created a Debian Bug too remove the sosreport from unstable, which was then re-titled by me to change from RoQA to RoM Bug #1095579

• Became Debian Maintainer on 26th January and since then have uploaded sos many times to unstable and `backports

• As continuous work on this, we created 2 PPAs under the sosreport team. One to have point releases which can help with potential SRUs, this also gives people access to latest code as verification can take so long. This is going to help with future rename in stable releases as the prep work has already been done. The second is a daily build so that we can we can potentially test new features as they come along. I have respective git repos that has all the modifications required, sosreport and sos

Areas of work

I work in the Support Engineering at Canonical, and we use sos as a regular tool for our support organisation, so haven't worked with a development team or developer directly per-se. Between myself and David Negreira we both contribute to upstream sos as well all the verification work that is required for sos SRUs.

For the SRU work, I have worked very closely with Dariusz Gadomski, Mauricio Oliveira and Heitor Siqueira who have guided me in the ways of ubuntu packaging and SRU process.

I have worked on many sos bugs, whether they have been internally within my team, through Github issues or Launchpad bugs.

• SRU of sosreport 4.7.2 LP #2054395

• Obfuscation issues faced in SRU for 4.7.2 LP #2085607

• msr module being loaded in focal and jammy LP #2089713

• sosreport upgrade from xenial to bionic LP #2038648

• Fix obfuscation issue from the state.json from snap plugin collection LP #1891296

• Password obfuscation issue of wireless password in netplan LP #2037872

• SRU of sosreport 4.8.2 LP #2091858

  • As part fof my work here we had autopkgtest flakiness for focal arm64, and was advised to do a MR for hints for britney

• Obfuscation/Collection issues in sosreport/sos 4.8.2 LP #2101134

• Username clean doesn't work in 4.8.2 LP #2102199

Previously, I have also helped with verification of new release SRUs for sos since 2020

Things I could do better

We can always do better, better testing and such.

I would like to improve the testing of the packages.

Be even more through during the verification tests. The last 2 verifications have shown some missing items that could have been discovered a lot earlier as the issues had been there for a long while.

Also, I would like to improve and we are working towards is getting more people involved with SRU verifications especially when we have new releases. One of my main visions over the next 6 months to a year is to improve how we do verifications, so rather than taking a 3 months (4.7.2), or 1 month (4.8.2) we could improve on the speed of getting things through. This is now one of the key steps that takes the longest.

Plans for the future

General

• The most pressing item is to bring the new renamed package with transitional package into stable releases. The assistance of the wider team will be required for the steps and the actions to be taken for this task to be successful.

• Keep improving and maintaining the sos packages for Debian and Ubuntu, and where needed mentor people to help maintain the package internally and externally.

• I am currently DM for sos and sosreport, and will continue to maintain the Debian package into unstable, testing and backports.

• I am also working on the avocado package which is the testing framework employed by the sos project. This will ensure that our autopkgtests would be more in-line with upstream and more fine tuned. This has been sponsored and into NEW into Debian. Q release and above are likely to take advantage of this and hence less likely for autopkgtests to fail randomly. Maybe, this is one package that we could backports, and help other series in the same way. ITP & RFS bugs

• Once the major work on backporting sos into stable releases, (time dependant) I'll start looking at some patch fixes and would like to help with some simple SRUs to build up my portfolio to potentially work towards MOTU

• Mentoring fellow colleagues who can then help with the whole process, as I am the only one now maintaining sos within Canonical.

What I like least in Ubuntu

On the key items is getting people to understand the concepts of snaps. I would like assist in helping to bridge that gap, so that people understand them better so that we can improve the overall.

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.

Lukas 'slyon' Märdian

General feedback

Arif worked on sosreport mostly, that's why he's requesting PPU for just that package. He's one of the upstream maintainers, and I trust him to be a domain expert on this package. sosreport does have an SRU exception (https://wiki.ubuntu.com/SosreportUpdates), so it's tracking the upstream developments closely and Arif can help with accelerating this.

Specific Experiences of working together

I've only worked on a single bug report with Arif (LP: #2054395), it was about bringing in a new upstream release of sosreport and backporting it to stable series. Getting it landed in all the LTS releases was a lengthy progress that he tracked for more than 6 months. He provided a solid SRU template/docs and addressed all the feedback that he received from several patch pilots over the months, honing the package into shape. At some point, I was able to sponsor his changes into the development release and stable series as SRUs.

This was one of his first uploads and he learned a lot from working on this. We talked on IRC, specifically about the Depends/Recommends/Suggests relationships between packages. And he codified those learnings by improving the upstream CI of sosreport accordingly.

Areas of Improvement

There's lots of stuff to learn in Ubuntu development & package maintenance. Especially about interdependencies between packages (e.g. transitions), the different components of the archive (e.g. "main" vs "universe") and corresponding tools and processes ("britney" https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html, "ben" https://ubuntu-archive-team.ubuntu.com/transitions/index.html or the MIR process https://github.com/canonical/ubuntu-mir#introduction). Most of that is not relevant for PPU of an existing package, thus I feel Arif is ready for sosreport PPU. I trust him to seek review/feedback when unclear or introducing bigger packaging changes. -- slyon 2024-12-12 13:39:23

Athos Ribeiro

General feedback

Arif's public facing packaging experience is mostly in within sosreport, which is the package he is requesting PPU for.

In Ubuntu, he worked on 2 updates setting the package version ahead of Debian and requested one sync with Debian. The other uploads seem to be all related to SRUs, either with specific fixes or backporting upstream versions all the way down to focal.

In Debian, Arif's uploads were sponsored 6 times as of the date I am writing this. These uploads introduced several improvements to sosreport to the point that all our delta was removed from the package and it bacame a sync with Debian (nice job there, Arif). It also got him to the point where the maintainer for sosreport in debian trusts him with the package, added him as an uploader for the package and is also advocating for Arif to become a DM for that specific package.

Finally, Arif is also an upstream developer of that package.

IMHO, Arif has enough knowledge of that specific package and of our processes to get a PPU permission to keep working on sosreport on his own. Do note that he also started the process to get a DM status for this package, which is currently a sync, and already have a (non-Canonical) advocate for that, which is also a good sign that he is ready for this.

Specific Experiences of working together

I Only worked with Arif in LP: #2054395 as part of my patch pilot shifts. Back then, Arif was still getting to understand our packaging processes. There was a lot of communication there both in the bug and offline, and Arif was always asking questions whenever he had any doubt. Arif is a really quick learner and understood the processes well after a few weeks working on that package.

Areas of Improvement

It would be nice to see Arif dealing with other packages as well if he would ever want to also apply for a MOTU or core-dev role in the future. It would also be nice to see Arif performing more and more uploads and SRUs so he can master both processes. Arif is ready for this PPU and I trust he will seek for help whenever in doubt of any of Ubuntu's processes.

Dariusz Gadomski

General feedback

I know Arif for several years now. We have been working for the same organization (Canonical Support). I have been able to get to know him on a professional and personal levels. He demonstrated his dedication to maintaining high quality of sosreport snap and deb releases. I have witnessed his dedication to understand the sosreport release process, getting in touch with upstream to discuss technical matters and determination to obtain the necessary context to be efficient and consistent as person responsible for sosreport.

Specific Experiences of working together

I have not sponsored directly any packages for Arif yet,I had numerous discussions with him about Debian packaging with a specific goal of taking responsibility for Arif taking over the maintenance of sosreport for Ubuntu and Debian. I answered a number of packaging related questions (related and not to sosreport).

Areas of Improvement

I believe there are things related to packaging that Arif needs to explore, but I am sure that he will be able to resolve any potential issues, reach out for guidance if needed and communicate anything the sosreport users need to be aware of. -- dgadomski 2024-12-21 15:46:41

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

CategoryPerPackageUploaderApplication