I, Aaron Rainbolt, apply for MOTU.

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.
• I'd like to be able to do my work as a Lubuntu Developer more easily by being able to add new packages to the archive without interrupting as many people.

Who I am

I'm a software developer living in the central United States, with a passion for helping people be able to use Linux more easily and on lower-spec hardware. I've been working with the Lubuntu project for over a year. In my free time, I generally do Bible studies (I'm a Christian), solve Rubik's cubes, watch YouTube, work on side projects, and talk/argue with people online.

My Ubuntu story

I first joined the Lubuntu project in April of 2022, shortly after the release of 22.04 Jammy Jellyfish. Initially I intended to assist with Lubuntu's documentation (since that was something the Lubuntu manual mentioned I could help with). I rapidly got sucked into debugging work, then learned how to package, fix bugs, do Python scripting, and a large assortment of other skills, resulting in me eventually becoming a Lubuntu Member, then Lubuntu Developer, then Lubuntu Council Member. I got to help debug critical bugs in Ubuntu Desktop, and also fixed a critical release blocker in Ubuntu MATE along the way. Sadly, a couple weeks later I had to take a six-month hiatus from development due to unfortunate life circumstances. I recently was able to return to Lubuntu and Ubuntu development, whereupon after proving I still had my skills I was quickly voted back in as a Lubuntu Member and Developer. I've made some... uh... interesting... mistakes along the way (like renaming a Featherpad tarball "Calamares" and mangling packages a few times), but I've since learned a lot and believe I can avoid making those mistakes in the future (and catch them if I do make them).

My involvement

Examples of my work / Things I'm proud of

This list intentionally omits things that I did prior to preparing for my MOTU application, as most of that work was Lubuntu-specific. I have worked on many more packages than this, including most if not all of the LXQt stack, caja (the Ubuntu MATE file manager), openbox, and Lubuntu-specific packages such as lubuntu-update-notifier and lubuntu-artwork. I have also worked on XScreenSaver in Debian.

• redshift-qt. This was a brand-new package created for both Debian and Ubuntu. It is intended to add a night color feature to Lubuntu 24.04. Using an existing LXQt-related package as a template, I got a Lintian-clean package that needed only very minimal fixes before it was ready for uploading to the Debian and Ubuntu archives. I was able to begin and finish packaging and get the package reviewed and sponsored all in one day. https://launchpad.net/ubuntu/+source/redshift-qt

• sc. Learned how to tell when to do a merge and when to do a sync. Bug report fixed by sync.

• efitools. My first non-Lubuntu-related merge. Bug report, merge debdiff was sponsored.

• jigit. Second non-Lubuntu-related merge. Bug report, merge debdiff was sponsored.

• munin. A slightly tricky merge with autopkgtests involved. Learned how to run local QEMU-based autopkgtests, as well as how to request autopkgtests to be run against a PPA. Bug report, merge debdiff was sponsored.

• samtools-legacy. Relatively easy merge, was sponsored as-is first time with no changes requested. Bug report.

• mlpack. Package simply needed synced from Debian. Sync request.

• pytables. Package simply needed synced from Debian... or so it seemed. Sync request.

• satpy. This was a reverse Recommends of pytables that may have entangled it during migration. It was failing to build from source. This turned out to be due to three issues. One, a weird issue related to "legacy resampler code" in satpy. Two, a mistyped assertion method in one of the tests. Three, an outdated dependency version check in a different test. Two upstream backports and a custom patch were needed to get the package to build properly. FTBFS bug report with patch. Upstream bug report filed to forward the custom patch upstream.

• show-in-file-manager. This just needed synced from Debian, but there was one possibly concerning Lintian gripe (missing-prerequisite-for-pyproject-backend) I got when building the package, so I fixed it and submitted an MR to Debian. Sync request. Debian MR.

• openmsx. Whew.
  • Initially I was just going to do a merge and call it a day. However, building the package revealed that there were multiple problems with the upstream Debian package, some of which were severe.

  • I then set out to fix the Debian package before doing the merge. This took multiple days, due to the high complexity of the package, the number of issues with the package, and the type of issues involved. Among other things, I ended up rebuilding the copyright file, finding sources for binary files that didn't have source included in the openMSX source tree, repacking to remove an unnecessary sourceless binaries, and fixing a failing autopkgtest caused by a too-new version of catch2 in the Debian archive (which was fixed by switching to the vendored version of catch2 provided with openMSX). Debian bug report.

  • I submitted the fixed package to the openMSX maintainer for review. After several iterations and a lot of discussion, a fix has been accepted and I'm ready to get this synced into Ubuntu (though I have not yet done that part). There's also some follow-up work to do with this package (discussed in the Debian bug) that I look forward to helping with.

• fxload. Relatively simple merge. Bug report, merge debdiff was sponsored.

• python-etcd3gw. Would have been a sync, but for some reason a missing JavaScript file was causing an FTBFS on Noble (but not on Sid), requiring an extra build dependency and a rules file tweak to resolve. Bug report, merge debdiff was sponsored with slight changes

• fonts-sahel. Fairly easy sync + delta, added some info to my checklist to help me catch when I need to add Breaks/Replaces. Bug report, debdiff was sponsored

• signond. Synced from Debian with minor changes, with the goal of replacing the signon package in Ubuntu. Ended up learning a LOT doing this one, including properly dealing with symbols differences between Ubuntu and Debian, what safeguards are in place for dealing with proposed migration issues, ideal ways of handling Debian and Ubuntu bugs, and I even set up a local Britney instance at one point (which ended up being pointless but I did manage to get it running). Bug report, debdiff sponsored with changes

• manuskript. This was an SRU into Jammy.

  • On 2022-09-09 (during the Kinetic cycle), it was discovered that the version of Manuskript in Kinetic and Jammy had a bug that caused it to crash immediately upon attempting to launch it when launching it with a too-new version of Python. (This was reported initially in what is now the Ubuntu Support Matrix room, and the person who initially informed me about it wrote the original bug report.) This bug was fixed in a newer version of Manuskript, but Kinetic was already in Feature Freeze, and my initial attempt and uploading a whole new version of Manuskript into Kinetic and getting it backported into Jammy was unsuccessful. The bug is at https://bugs.launchpad.net/ubuntu/+source/manuskript/+bug/1989203.

  • A backport of the commit fixing the bug was attempted and initially appeared to work. Sadly it failed due to other Python incompatibilities, and ultimately the bug was left unfixed for over a year.
  • On 2023-12-27, I attempted a second patch, which actually worked in my testing, and requested sponsorship for it, which Simon Quigley provided. mfo had to tweak it due to a mistake both me and Simon overlooked, but the latest iteration of the patch seems to work. Currently the patch is awaiting review by the Ubuntu SRU team.

In addition, I successfully completed a patch piloting session with Simon Quigley doing package uploads for me and providing me guidance (with additional input and guidance from rbasak, vorlon, and some help from sudip who's packages I was reviewing). In the process, three packages were sponsored: libtrace3, zeitgeist (which needed a slight tweak), and horst (only the Noble package, the SRU portion of the bug wasn't handled that day). The logs of the session can be seen at https://irclogs.ubuntu.com/2024/01/03/%23ubuntu-devel.txt. The patch pilot handoff post for this session is at https://discourse.ubuntu.com/t/patch-pilot-hand-off-24-04/39509/42?u=arraybolt3.

Areas of work

The majority of my work has been in the Lubuntu project, doing things such as updating the LXQt stack in cooperation with other team members, fixing installer bugs, cooperating with upstream devs to get bugs fixed, auditing source code licensing, and QA-testing ISOs. I've also worked with the Release team in testing LTS point releases (helping to catch and debug a critical blocker related to Firefox in 22.04.1 at one point), and have done some work with the MATE team patching a memory management error in Caja. My work has resulted in Lubuntu users having newer software with fewer bugs, and has helped keep Lubuntu modern and usable.

Recently, at the suggestion of Simon Quigley, I've been working on maintaining packages in Universe, doing merges and syncs from Debian and fixing bugs in the Ubuntu delta of those merges. I've learned a lot more about packaging doing this.

Things I could do better

I sometimes pay so close of attention to certain parts of my job that I forget other parts of my job and needs others to remind me. I should probably be building a running checklist of things that need done before doing an upload, or before setting up a PPA, or whatever, to help me with that. I've been relying on peer review to catch these sorts of things up until now and will need to be able to do without that in some situations in order to be a MOTU. I have already started building such a list.

Plans for the future

General

Obviously I intend on continuing to develop Lubuntu and help out with maintaining packages in Universe as I can. Being an MOTU will help me be able to do both of those things more effectively (specifically in the context of Lubuntu, I won't need to worry about upload rights when new packages have to be introduced or when some package outside of the Lubuntu packageset has a bug that directly influences Lubuntu). I'd also like to do patch piloting eventually. I don't have massive plans for revamping Ubuntu as a whole - it's already a seriously good OS that I'm happy to use on a daily basis (and have been using on a daily basis for years).

One idea I've been thinking about recently however is the ability to make hyper-minimal Ubuntu installs via debootstrap (something I do regularly in my development work - I find this highly handy for making minimal VMs). It would be cool if there was a tool that made this sort of thing easy, and I even have a name for it - Ubuntu Flex (or ubuflex until I get permission to use the Ubuntu name on it). Basically the idea is to make an Ubuntu netinstaller using debootstrap, apt, and a few other tools, allowing someone to do non-standard installs like Ubuntu with IceWM and stuff like that. I think it would be useful, especially since I do this sort of thing by hand already.

What I like least in Ubuntu

Ironically, my least-favorite part of Ubuntu isn't anything technical about it. It's the code name convention that gives me slight anxiety. Why? We all love cool codenames like Kinetic Kudu and Lunar Lobster, but every one in a great while a codename comes up that I'm personally uncomfortable with. One was Wily Werewolf, and the other most recent one is Mantic Minotaur. I get that to most people these names don't have a lot of significance, but for me personally, names that reference evil monsters are problematic, as they oftentimes carry religious significance that conflicts with my beliefs.

I don't really have any ideas on how to fix this other than to ask really nicely, so hopefully this is me asking really nicely If we could always choose animals that actually exist for the codenames, that would very likely eliminate the problem for me.

If I have to pick something technical I dislike about Ubuntu, I suppose it is frustrating that systems that use Intel RST technology with NVMe SSDs don't allow Ubuntu to install to the primary SSD without switching the system out of RAID mode (and not all systems are able to be switched out of RAID mode). There's a patch for the Linux kernel that corrects this issue, but it wasn't accepted into mainline Linux since (IIRC) it messes with Linux's SSD quirks handling. Personally I'd rather be able to at least try to install Ubuntu and have it likely work rather than be totally unable to install, and Endless OS seems to find the patch safe enough to ship, so perhaps it would be worth the Ubuntu Kernel Team's time to consider. Link to patch.

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

I have had the privilege to work with arraybolt3 on the Lubuntu team. When I type privilege, I really mean it. arraybolt3's work ethic is amazing and his ability to learn things quickly is unparalleled. He takes advice very well and does research into issues. He knows the Debian Policy very well. He has a decent amount of experience working in both Debian and Ubuntu. The quality of work is excellent and he doesn't hesitate to ask questions when needed. arraybolt3 is very collegial with communication and you can find him all over the Ubuntu IRC/Matrix channels as well as Discourse. He provides excellent support with experienced examples for folks to solve their issues. arraybolt3 is an excellent fit to join the ranks of MOTU. -- kc2bez 2023-12-11 02:03:46

I am not a developer, so I won't attempt to consider the technical aspects of this application. Aaron however has shown himself to be passionate, energetic and is a valuable member of the Lubuntu project (as probably evidenced by his very rapid acceptance after standing down for the mantic cycle). I believe the Ubuntu Project would benefit more if Aaron was a MOTU. -- guiverc 2023-12-11 04:20:59

Endorsements

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

Simon Quigley (tsimonq2)

General feedback

Please read my endorsement of Aaron on the mailing list, including all attached links: https://lists.ubuntu.com/archives/devel-permissions/2023-November/002373.html

As an update from this time, Aaron continues to refine his knowledge. He has completed more than 15 non-Lubuntu Universe uploads in less than a month, and shows in later uploads that he learns from his mistakes. Some of these uploads were syncs, but many of these required a lot of willpower.

In mentoring new applicants such as Aaron, I often think back to my own experiences in Ubuntu. One experience I will never forget is gaining Ubuntu Membership (at 14); after only three months of contributing, half the time normally expected for applicants, I ambitiously applied and was granted Ubuntu Membership. A year or two later, I became a member of the Ubuntu Membership Board, and decided to read some historical context, including my own membership process. I was surprised to read that there was uncertainty, but I will never forget what they decided in the end: despite only three months of contributing, they recognized my energy, level of existing contributions, and knowledge about the community, and decided to give me a chance. After reading that, I was sure to not let them down. I strongly believe we have a similar case here: Aaron has an incredible amount of enthusiasm and ambition, and should be unblocked in his efforts.

After sponsoring 46 uploads for Aaron (at the time of writing), I understand his packaging style well: https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=Simon+Quigley&sponsor_search=name&sponsoree=Aaron+Rainbolt&sponsoree_search=name

He is meticulous about copyright updates. If one minor element is wrong, or if a copyright file needs to be rewritten, he just does it, correctly the first time (most of the time, there's been maybe one or two incredibly minor exceptions), without hesitation. As a Debian Developer, I am shocked at times when Aaron brings up DFSG compatibility points that I had not thought about. (It makes me want to re-read all of my licensing documentation.)

Aaron is also quick to solve any issues arising from his uploads. I cannot think of a time where he has uploaded something broken and has not fixed it within 24 hours. He is incredibly responsive in #lubuntu-devel six days of the week, and does work outside of the direct, collective "duties" we share as Lubuntu Developers.

While Aaron is incredibly well-read, deeply knowledgeable about the DFSG and Debian Policy, and intimately familiar with Britney[a] and Ubuntu's Proposed Migration policies, we suffer from a common "downside": when a good song is playing, you're just doing the regular LXQt packaging churn each cycle, and you've already uploaded 10 packages that day, you tend to go fast. Every once in a while, this leads to mistakes that would not have occurred had you taken a second look. This happens to the best of us, but I would say it happens more frequently with newer contributors. I would argue that Aaron goes slowly when touching critical pieces of the stack, but like any new contributor, could slow down a little bit at times on the normal churn. [a] https://lists.ubuntu.com/archives/ubuntu-devel/2023-December/042853.html

That all being said, I, Simon Quigley, strongly believe that Aaron Rainbolt is ready for, and should be entrusted with, Ubuntu Master Of The Universe permissions, immediately.

-- tsimonq2 2023-12-11 02:25:09

Erich Eickmeyer

General feedback

I have been helping to mentor Aaron on packaging practices for about the past two years, and he has been a quick learner. One of the first packages I gave him was a very large package that I started years ago that to this day remains unfinished, mostly because it's very painstaking in the long copyright. I haven't even finished it and there's a very likely chance it will never be finished simply due to time constraints. However, it gave him a good exercise on DEP-5 copyright that I believe has served him well with his packaging experiences as his packages have been very meticulous with the copyright files when I have reviewed them.

Aaron is very tenacious and booksmart, especially when it comes to the Debian policy. He knows where to look if he doesn't know the answer, and if he can't find the answer, he knows who to ask, whether it be myself or Simon. Barring that, he's not afraid to reach out in #ubuntu-devel on IRC to ask questions.

One example of superior judgement is where Aaron was forwarding a bug upstream to Debian and making a judgement call there. We discussed the severity where I was (unbeknownst to him) intentionally arguing a higher severity to make him think about whether the lintian warning was a true policy violation or simply a bug in the packaging. He successfully argued it should be "normal" severity since it wasn't a policy violation but was having trouble justifying it. I pointed him at prior bugs in similar situations where it should be normal, showing he was right.

I see no reason, based on his understanding of packaging and Debian policy, why he should not be granted MOTU. He has shown competency in packages that have brought him out of his LXQt comfort zone, including some multimedia packages that I normally oversee.

Areas of Improvement

The only areas I can really see Aaron improving in is when it comes to where the Debian or Ubuntu policy is silent and he needs to make a judgement call, such as what order to forward a bug to Debian. However, this should not preclude him from receiving MOTU permissions.

-- eeickmeyer 2023-12-11 04:10:12

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

CategoryMOTUApplication