ServerUploaderDeveloperApplication

I, Mitchell Dzurick, hereby apply for Server package-set.

Name

Mitchell Dzurick

Launchpad Page

https://launchpad.net/~mitchdz

Wiki Page

https://wiki.ubuntu.com/mitchdz


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 unblock other people & further help them get things done! \o/

  • I'd like to further my goals of getting core-dev.
  • I'd like to help contribute to this amazing Linux community.

Who I am

I am a CPC engineer at Canonical in the AWS team. This just means that mostly anything related to packaging that AWS needs is something I look after, or is the first contact to triage. I've also participated in a lot of packaging work outside the cloud, mainly Friday bug triage for server and handling various bugs here and there.

School wise I have a masters in Computer Engineering from the University of Arizona, where I graduated with this degree in 2021. While at university, I was the president of the school IEEE branch and a club called HACKS which has a server room and we did fun things such as maintain servers and hack older systems/software. We also had fun exploring an Ubuntu version with dirty cow on it :). While doing cshool I TA'd for intro to computer architecture, which was a class on architecture using Verilog. In addition to that I worked part time for Intel as a Software Security Engineer intern.

Professionally I started my first job as a Software Security Engineering intern for Intel within the IOTG group. In this group my main work consisted of building the operating system for a new product called Trusted Edge Platform or TEP. This was a stripped down lightweight and secure ACRN based type 1 hypervisor. This is where I got a lot security related experience such as tpm2-pkcs11 work, and I also worked with SGX a little bit. These images were built using the Yocto build system, which is where I learnt a ton of skills relating to the kernel/OS. Mainly I got a ton of exposure to systemd, and removing unnecessary code such as kernel modules we don't plan to use.

After graduating, I joined the Intel ASV team as a Systems Validation Engineer. At this position, my job was to validate the compression engine of the intel QAT which is an on-die accelerator in Sapphire Rapids. This is a compression accelerator which can compress up to 160Gb/s, and I got _very_ familiar with RFC 1951. My work in this team varied quite a lot from developing a python based test framework, to writing custom firmware for the accelerator, debugging custom drivers, and lastly packaging tools and code to my colleagues. We did all of our work in Fedora based docker containers with our tools pre-packaged in. I found that when debugging specific issues there was a lot of toil with getting the right tools in the dev environment, so I took it upon myself to start organizing the tools and made an rpm package to be distributed in the new dev containers. This sparked my introduction to packaging in a corporate environment and ultimately led me to joining Canonical.

Outside of work, I maintain a homelab environment where I have multiple type 1 hypervisors and like testing out new software and technology. One of my favorite technologies to mess around with is guest PCI passthrough with VFIO mainly for near-native gaming performance in gaming VMs. Unfortunately my main gaming system does not use this setup anymore due to my main games needing malware level cheat detection software :(.

My Ubuntu Story

My first distro of choice was Ubuntu (surprise!) which I ran as my daily and only OS starting sophomore year of college. I think running Linux as your daily is probably the best way to really get your feet wet. There's nothing like frantically fixing your broken kernel at 11pm before the 11:59pm submission deadline because you decided "hey, let's try messing with the currently running kernel instead of submitting my homework assignment in".

I am someone who loves to try and compare multiple softwares, so I did try multiple other distros such as Manjaro, Arch, Puppy Linux. I decided to land on Ubuntu because a lot of the software I needed for school specifically supported Ubuntu such as Vivado/Matlab. In addition to that, I enjoyed the stability that Ubuntu offered and as a newish user most problems I encountered I could easily find other people having the same problems and fix them myself.

I've always looked up to the developers of Ubuntu and envisioned one day I could help develop these packages I used to rely on, I just didn't imagine it would happen this soon in my life.

Package Merges and Syncs

Bug Fixes & SRUs

Bug Triage

Autopkgtest & DEP8 & Testing

Milestones and Exceptions

Proposed Migration

Things I could do Better

  • oversubscribing to multiple tasks
    • I have a habit of taking on a lot of tasks which I have been fine in the past, but packaging work is a little different because to really finish a task you need to look after the package the whole time, and sometimes I would not plan for things to go wrong in the final step and not have time to look after the package.
  • rabbit holes
    • I love digging deep into software and finding out why things work, sometimes that's just not necessary and I end up wasting time. Sometimes it does work out though.
  • Get more involved in IRC
    • I plan to do more +1 help as I find this is my favorite way to get involved with IRC, otherwise I'm not too sure what to talk about.
  • Get more involved with debian
    • I would like to ultimately become a DD, but have just struggled to find packages I care about a lot. I've started to pinpoint a few.

Plans for the Future

General

With the server packageset rights I plan to help ease the burden of my server team colleagues with reviews and sponsorships. I also plan to help out with +1 maintenance more which these packageset rights could be very valuable for that kind of work.

I would also like to start mentoring people more, I haven't had much of an opportunity being one of the more new people in the packaging space, but having the rights to sponsor packages would help me be able to mentor individuals. In the same line of thought, these packageset rights will help me give back to the community and sponsor packages from community friends.

Lastly I want these packageset rights to help my long-term goal of becoming a core-dev.

What I like least in Ubuntu

What I like least in Ubuntu is also one of the things I like most, which is the SRU process. In certain applications it can feel unnecessarily burdensome, but I think that's by design as we take a stance of stability being the primary focus.

Endorsements

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

Bryce Harrington

General feedback

I've handed off a number of packaging items to Mitchell and worked closely with him through the process of getting them resolved. I've been impressed with his diligence and resourcefulness, good questions, and follow-through.

I'm glad to see Mitchell applying for PPU. It's an established adage that you know you're ready to apply for upload rights once people are surprised that you don't already have them, and well I had thought Mitchell was already PPU and am surprised!

Specific Experiences of working together

I had inherited a duty to maintain multipath-tools to offload a co-worker moving on to other tasks, but it was not a package I was familiar with or enjoyed working on, and had some complex packaging issues that I'd worked through about 80-90% on but it needed a bit more work and polish. Mitchell had just recently started at Canonical but had mastered the onboarding beginner-level work and was looking for something a bit more challenging to seek his teeth into. I offered to let him take the multipath-tools merge from me, and he enthusiastically agreed. It turned out very well, since he could follow the work I'd done as a learning exercise as well as a puzzle to ferret out and solve the remaining issue and get the merge successfully completed.

He then used that experience as a springboard to tackle some of the other multipath-tools issues that had been orbiting the server team, and in fact has taken over the package maintenance duty entirely! Needless to say I feel this worked out perfectly all around; multipath-tools is in much better hands.

Some of the other items I've collaborated on have been smaller in scope but I've been no less pleased in how they have turned out. He discovered a branding regression in Apache2, solved it in an SRU and added a test case. He's taken responsibility for several of our team's "Housekeeping" bug work priorities, currently including a MIR for enabling a more modern email authentication functionality (DMARC) in Ubuntu's email servers.

Areas of Improvement

Make sure to participate in doing MP reviews ( https://code.launchpad.net/~canonical-server-reporter/+activereviews ); even though you may not be able to sponsor uploads I think you have enough packaging experience to be valuable as a reviewer, particularly on things in your areas of familiarity. Getting MPs through review helps the whole team be more productive, plus reviewing other people's work is a GREAT way to learn and spread tips and techniques. I'd suggest bookmarking that link and setting aside some specific time(s) of the week to check it as part of your general routine.

If your next step will be MOTU, then that will require a gear shift to look for work OUTSIDE your areas of familiarity, such as desktop or kernel packages, or in programming languages you don't know. It can be challenging to find ways to make these fit alongside your regular work expectations, all I can suggest is plan ahead and be diligent at carving out time to work on it. Importantly, for MOTU it's not just the packaging technical work; there is some social aspects to understand the various maintenance communities and the diversity of maintenance practices they've standardized on. A good MOTU application will show you've mastered a lot of different ways of working on packages, and that you've built relationships with several of these communities.

Lena Voytek

General feedback

I have sponsored several packages for Mitchell, including merges and fixes for spamassassin, byobu, exim4, and python2.7. Every time I review something for him it tends to be near perfect from the start, and any updates that are needed happen quickly. He has been incredibly helpful in reducing the amount of server package bugs in Ubuntu, and having package set upload permissions will help him branch out with packaging even more.

Specific Experiences of working together

When Mitchell joined Canonical I was designated as his mentor for packaging related tasks. He quickly got up to speed started fixing bugs almost immediately. I also worked with him on some initial bug triage runs, and he was able to take over the full process for Fridays which I used to be scheduled for. Now I mostly help with specific technical questions and reviews on package fixes.

Areas of Improvement

I think it would be a good idea for Mitchell to do more reviews for others. He can further his packaging skills by reviewing specific cases from our team, and with upload permissions he can help sponsor fixes from community members.

Athos Ribeiro

General feedback

As per the report in [1], I have only sponsored a single change (across many supported series) for Mitchell. That was one of the first changes submitted by Mitchell in Ubuntu and there were a few rounds of reviews for that patch.

Back then, Mitchell was already quite diligent when submitting patches and making changes. I have been involved in other discussions related to Mitchell patches, SRUs and MREs. It has been really nice to see how fast he has been picking up on all the packaging tasks a core-dev needs to perform and understand and I am glad he is applying for his PPU rights. It will be of great help to the server team and an important step on his road to getting core-dev permissions.

[1] https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=*ribeiro*&sponsor_search=name&sponsoree=*Mitchell*&sponsoree_search=name

Specific Experiences of working together

Mitchell has shadowed me while performing specific MREs and triaging bugs related to the server packages. He is now quite proficient in doing both as per the records shown in his application. As per packaging changes, the only package I have sponsored for Mitchell is the one linked in the previous section [1].

Areas of Improvement

It would be nice to see Mitchell working in package transitions so we are sure he understands what it takes to complete one. Maybe getting MOTU right away or in a near future could be a first step towards that goal. Then, I suppose he would have all the experience and knowledge to apply for his core developer rights.

AndreasHasenack

General feedback

Mitchell has demonstrated to me the ability to dig deep into troubleshooting sessions, and after identifying the fix, correctly applying it to the corresponding Ubuntu package. Mitchell also works very hard to get a reproduceable test case, which shows that he really understood what was going on, and demonstrates that the fix is correct. This can be seen in detail in his work on multipath-tools, where he tested even more complex scenarios like booting from a multipath device.

Specific Experiences of working together

Sponsored packages: https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=*hasenack*&sponsor_search=name&sponsoree=*mitchell*dzurick*&sponsoree_search=name

* multipath-tools

Bug #2000186 in particular turned into something much more complex than anticipated, involving old SysV debhelpers and moving to systemd, and a lot of careful maintainer script analysis. To complicate things even more, this package has a socket systemd unit, to start the actual service only when needed. On other words, this bug touched a lot of areas around debian packaging: - maintainer scripts (postinst, preinst, etc) - transition from sysv to systemd units - systemd socket activation - test plan - regression risk

And all of the above in an SRU. No small feat.

* nbd

Clean cherry-pick of an upstream patch, with good test plan and both devel and SRU uploads.

Areas of Improvement

Please do more reviews, your input is very valuable.

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

mitchdz/ServerUploaderDeveloperApplication (last edited 2024-05-27 15:19:37 by ahasenack)