Application-PPU

I, Frank Heimes, apply for upload rights for package(s) s390-tools and s390-tools-signed.


I am applying because:

  • I'd like to reduce the burden on my sponsors.
  • I'd like to reduce the time needed for getting uploads done, esp. for the s390-tools*.
  • Since signing is involved, special approval by the release team is needed, hence uploading these packages (even to devel) will not make them directly land in the archive.

Who I am

I'm a an computer and electronics guy located in Germany that grew up in the Rhine/Ruhr area close to Neuss/Düsseldorf and later moved to Böblingen - for business reasons.
I'm now living at the Schwäbische Alb (English: Swabian Jura), in a municipality called Winterlingen (district Benzingen) that is actually in the middle of nowhere (half-way between Stuttgart and Lake Constance, but very nice and scenic.
I'm living there with my wife Steffi and Lilo our cat.
I like to spend time at the computer, even in my spare time, like to travel - cuddling Lilo and taking care about the garden and my rattly classic car.

My Ubuntu story

At my previous employer, IBM R&D lab in Böblingen/Germany, I worked for 15 years in the area of Linux, in the second half with Linux on Mainframes - mostly with SLES and RHEL. But at some point in time a volunteer workstation OS project started at big-blue (called Open Client Debian Community, OCDC) and I became involved and maintained a dozen of packages (since the other Linux distro that could be used on the workstation sucked on desktops - imho).
Even if it was called Open Client Debian Community, most people in that community used 'Ubuntu'.
So I strove Dapper Drake / 6.06 LTS and really started to fell in love with Hardy Heron / 8.04 LTS (on private and business machines).
A couple of years later, a company called 'Canonical' was looking for someone to help-out with getting Ubuntu (Server) enabled for s390x, I thought that this is a good fit and the next thing I want to do - which ended in me joining Canonical early 2016. Since then I'm a member of Canonical's Partner Engineering / PE team (former Server Commercial Engineering / SCE, former Hardware Enablement / HWE), mainly working on IBM Z (s390x) and IBM POWER (ppc64el).

My involvement

Examples of my work / Things I'm proud of

(focusing here on the package set I'm applying for)

I did about 30 s390-tools package updates on different Ubuntu releases (SRUs, patches and version bumps in devel) in the last couple of years. I learned quite a lot (more) on packaging, with several things that were introduced with new s390-tools versions, like:

  • creating s390-tools packages also for non s390x architectures (with reduced content) and ensuring that the 'Architecture: all' build is done on s390x (instead of amd64), using 'XS-Build-Indep-Architecture: s390x'
  • new tools that were upstream implemented in Rust, so building Rust code (in a main package), with everything needed on top (like vendored crates) - also thx to Simon/Foundations
  • have the PEM file incl. in s390-tools-signed so that it can be added manually to a system (preparing for upcoming mainframes generations, that may no longer ship it integrated in firmware.) - also thx to Dimitri/xnox

Please see some selected uploads, that I would like to reference here:

In addition I did some upstream work, that can be found here:

Areas of work

Let us know what you worked on, with which development teams / developers with whom you cooperated and how it worked out.

For the bigger picture about the work I did on s390-tools and s390-tools-signed, please refer to the full changelogs:

For further work (also beyond s390-tools*) please also see:

The work that I am doing if mainly driven by the projects I'm responsible for (but not limited to them), like s390-tools, libica, openssl-ibmca, libzpc, opencryptoki and also kernel.

Things I could do better

  • Learn even more about Ubuntu Release Management transitions.

  • Be more '-EvIL' and '+pedantic'.

  • Avoid by-passing Launchpad for bug work and communication (well, but some topics just need to be discussed non-publicly).

  • Have a closer look at Debian

Plans for the future

General

What I like least in Ubuntu

  • That it is virtually impossible to address all bugs that come in via Launchpad.

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

I know Frank since 2020, since when we have supported each other several times. He helped me figuring out how to run an installation of Ubuntu on (and getting access to) 'big-iron' s390x machines, that was needed for debugging an early-boot (initrd) issue in my role as an Ubuntu Foundations Engineer and I helped him with his packaging efforts on s390-tools and pcre2. Frank is very much on top of all his bug reports and wanted to move faster (not waiting for peers to help with solving certain issues), therefore he started contributing patches (for foundations-owned packages) himself. I reviewed several of those patches – mostly for s390-tools[-signed], which has quite some special bits to it (wrt. to package signing on Launchpad) – and uploaded those into the devel and stable (SRU) series. In the beginning I had some minor comments about his patches and Frank was really quick and motivated about reading up on and learning from the feedback, incorporating it into the next uploads. With each patch submission he improved the quality and reached a very good level. Frank is very pleasant to work with, understands the Ubuntu processes and he is strongly connected within Canonical and the Ubuntu community; I fully trust that he's making decisions in the best interest of the Ubuntu community.

Specific Experiences of working together

I sponsored s390-tools[-signed] and pcre2 into main and can assess Frank's motivation and quality of packaging work. The uploads I sponsored for Frank have been of high quality and Frank wasn't shy to ask about any uncertainities when preparing those patches. He has mostly been working closely with s390-tools upstream and then incorporating/cherry-picking certain patches into the Ubuntu packages for the development and stable series; following through on the full SRU process, always on top of his bugs and responding quickly to sponsor or SRU team requests.

s390-tools

2.15.1-0ubuntu6

s390-tools

2.14.0-1ubuntu1.1

s390-tools

2.12.0-0ubuntu3.2

pcre2

10.37-0ubuntu1

s390-tools

2.17.0-0ubuntu2

s390-tools-signed

2.17.0-0ubuntu2

s390-tools

2.16.0-0ubuntu1.1

s390-tools-signed

2.16.0-0ubuntu1.1

s390-tools-signed

2.12.0-0ubuntu3.4

s390-tools

2.12.0-0ubuntu3.4

Areas of Improvement

The version bump for pcre2 might have been a bit rushed, that was due to the FeatureFreeze being close. The version bump included a soname bump in the library and triggered a small transition that we needed to work out after the freeze. Not a big deal but I'd recommend learning more about transitions (https://people.canonical.com/~ubuntu-archive/transitions/index.html) to better understand the impact of library version bumps.

-- slyon 2024-07-08 09:42:04

Simon Chopin

General feedback

I've known Frank since I worked at Canonical, and worked closely with him on s390x matters as part of my role in Foundations since 2022, where I acted as technical liaison for Partner Engineering. While I was expecting having to investigate issues on behalf of PE, that role very quickly turned into advising Frank and reviewing his work before uploading.

I watched his technical proficiency grow with each upload, to the point where "PPU when?" has been my de facto reply to the last few s390-tools sponsorship requests. Frank has been eager to learn, and virtually never made the same mistakes twice. He's also always been very proactive in seeking help when faced with new situations, such as when s390-tools upstream started incorporating Rust code, and including in package where he already has upload rights, e.g. opencryptoki.

Specific Experiences of working together

It is worth noting for the record that most of our exchanges happen in private in informal chats rather than through formal reviews on the bugs, which I realize now isn't ideal for this kind of application!

I have more than 20 sponsored uploads for Frank, most of which were good work. In particular, I'll highlight this one (which isn't even on the list since the upload is in my name):

https://launchpad.net/ubuntu/+source/s390-tools/2.30.0-0ubuntu1

I had done the initial work for the Rust packaging in the previous upstream version, but they made some changes to how the Rust code was built. Rather than asking me to adjust the packaging, Frank took the time to properly understand the ins and outs to do it himself.

An example of a small failure on both our parts is https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/2025781

where the initial submission was FTBFS because of a missing binary in the debdiff (not visible on the public record, see above).

Areas of Improvement

Frank is proficient at the individual package level, but his contributions so far are usually on packages with little to no reverse-dependencies. It could be interesting for him to try his hands at helping out in transitions involving multiple packages.

-- schopin 2024-07-09 15:36:49

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

FrankHeimes/Application-PPU (last edited 2024-07-10 07:27:36 by fheimes)