CoredevApplication

Revision 41 as of 2017-12-12 14:03:49

Clear message

I, Andreas Hasenack, apply for Ubuntu Server Developer

Name

Andreas Hasenack

Launchpad Page

http://launchpad.net/~ahasenack

Wiki Page

https://wiki.ubuntu.com/AndreasHasenack

Who I am

I graduated in Electrical Engineering. Worked for a few years in a company in the aerospace industry, but in the civilian area, in a project about installing "black boxes" in trucks and buses to monitor several driving and engine parameters. I then came in contact with a customer who had a nice "intranet" (that's what it was called back then), with internal web sites and a big database backend (oracle). We had to do some development for them, but didn't have access to Oracle, and someone told me that I should try this thing called "linux", "postgresql" and "apache". I did, then installed it at home, and never looked back.

In 1998 I took a post-grad specialization course in the University (a degree higher than graduation, but below masters) in computer networks and went to work for Conectiva, the Brazilian Linux distribution, later renamed to Mandriva, where I stayed until 2008 doing lots of packaging work (RPM) and consulting for enterprise customers in the server area. My main area of expertise was email, authentication (kerberos, pam) and LDAP, and I also spent about half the time working in Conectiva's security team and doing security updates for the distro.

My Ubuntu story

Tell us how and when you got involved, what you liked working on and what you could probably do better.

My involvement

In 2008 I applied for a job in the Landscape team (https://landscape.canonical.com), and got hired as a QA engineer. I had never done any Debian packaging before, just had some ideas about how it worked, had grabbed a few packages here and there to inspect them, looked at patches, etc. apt-get wasn't a stranger, since Conectiva developed apt-rpm back in the day, and the concept of dependency resolution is the same everywhere.

Landscape has a client component, and that means a Debian package that gets installed on machines. It obviously needs to be QA'ed. So that's how I got exposed to Debian packaging "for real" that time.

In April 2017 I started working in the Ubuntu Server Team. That got me back in touch with my "Linux roots" (no pun intended) and immediately I started looking into my old friends kerberos, ldap, samba, etc and searching for bugs to fix. It is in the Ubuntu Server Team that I got introduced to the Debian Merge process, and how this team is looking into improving that process via the Git Ubuntu tooling.

Examples of my work / Things I'm proud of

My uploads. While I was working in the Landscape team, all my uploads were related to that. A clear change can be seen in May 2017 when I joined the Server Team. There were of course other bugs and fixes I worked on, but they were on the server part of Landscape which is a proprietary product. After that, we can see my tendency to work on authentication and LDAP.

  • landscape-client upload: caught a missing patch hunk (see comments #9 and #10) that prevented the fix from working. Updated the patch in my branch)

  • SRUs in general: I believe I'm good at coming up with good and simple test cases that anyone can follow by just copying and pasting commands. I really dislike SRUs whose testing section has just something like "setup an ldap server with kerberos authentication". That's way too heavy lifting for the tester. Here are some of my SRU examples:
    • SSSD: #1684295 worked with the reporter to get a crash file, then identified the issue, applied the upstream fix and came up with a much more simplified test case than the original environment. Reduced the scenario from multiple Active Directory servers to a localhost openldap instance with just a few entries and a single command to reproduce the segfault.

    • SSSD: #1664566 simple bug and fix, but testing it involves setting up SSSD with Kerberos 5, and some authorization source which is usually LDAP, but which I managed to avoid. The test case may look long, but it's detailed and has a simple step by step sequence.

    • pam-mysql: started as an "undefined symbol" bug (#1574900) which became something much more interesting (#1574911). Basically the libmysqlclient my_make_scrambled_password() function was unexported, then exported again but with different behavior. So we went from "undefined symbol" to segfaults. I came up with a patch that generates the same hash using openssl, which we already linked to. That MP also details the reasons for this approach and has detailed testing instructions, which were also used for the SRU itself.

    • libapache2-mod-auth-pgsql: #1698758 shows my approach to fixing bugs where I explain why the bug is happening and provide detailed test cases with step by step instructions to verify that the bug is fixed.

    • libvirt: #1707400 was an interesting bug to track down. It has 10 duplicates at the time of this writing and never had enough information to be properly diagnosed. I finally managed to reproduce it, and the whole story is explained in the SRU template.

    • openvpn-auth-ldap: (#1602813) two probably difficult services to setup and configure: openvpn (because of SSL certificates) and LDAP (because of, well, LDAP). This package had a segfault bug that was pretty simple to fix, but getting a simple test case up for people to validate the SRU sounded difficult. I think I managed to come up with a simple test case, though, that avoided the need of a populated LDAP server and still showed the segfault and verified that the fixed package didn't crash.

    • krb5: #1683237 was probably one of the most complex bugs to come up with a test case for. It requires setting up a kerberos and DNS server (bind9) with specific records in it. I still came up with a step by step guide, but it was quite long.

    • krb5: #1688121 had a simpler to setup test case, but a bit harder to analyze.

  • DEP8 tests I added:

Areas of work

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

Things I could do better

  • When doing reviews, I find it hard to ask for changes when they could be seen as "nit picking". I cave in too quickly. Sometimes they are indeed "nit picking", but other times I feel like my request would improve the quality of a package or code. But then I think to myself "nah, I can do that myself later, let's unblock this MP".
  • I need a better grasp of config file handling in maintainer scripts
  • debconf is a mystery to me
  • I'm still not 100% comfortable with the git workflow for merges. I get the idea, and I have done my own merges, but I find myself staring at merges done by others and there are things I just can't grasp yet why they were done that way. I need to do more merges of my own and get *different* people to review each.

Plans for the future

General

  • Add DEP8 tests to the packages I'm familiar with
  • Help make 18.04 an awesome LTS
  • Make sure LTSs get bug fixes

What I like least in Ubuntu

Please describe what you like least in Ubuntu and what thoughts do you have about fixing it.

  • LTS bugs really pile up Sad :( I like doing SRUs, specially for LTSs, as that tells our users that we do care and we don't need them to keep updating to the latest and greatest version all the time.

  • Some packages have 3 "initscripts": sysv, upstart and systemd. Which one is used can be complicated to find out. For example, see #170312 c9 where just the "reload" action from /etc/init.d (SysV) was taken and all other actions came from systemd. That's because the systemd service file didn't define a reload method. This needs cleanup.

  • Sometimes we refrain from fixing a bug in Ubuntu because Debian also has the bug, and we rather have them fix it first and then sync than introduce or increase the delta we have with them. I think we should not be so afraid of the delta as long as we:

    • document it properly: DEP3 headers
    • have an expectation that it can be dropped soon
    • use the git workflow
    • file a bug with Debian including the patch, and upstream when that is the case
    • determine that the fix is important for our users and that further delays are not desired
  • Many SRU bugs I see being accepted lack proper test cases. In many cases they are way too generic, or do not fulfill this requirement from the SRU template: these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem.


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

Andreas is one of the one engineers with the most dedication to quality and correctness of solutions that I have ever met. He also has an impressive skill for thinking outside the box, both in terms of how to poke holes in a piece of code and in how to troubleshoot things on an Ubuntu system. I'm a little surprised he's not a server dev already! -- tribaal 2017-11-28 14:57:42

I worked with Andreas on severals occassions over the years. He is very meticulous and pay attention to details, even the smallest one. I had the chance to see him in action while reviewing recent uploads for landscape-client. I also recently collaborate with him on the ubuntu-advantage project to enable fips and livepatch features. Andreas uploads are all high-quality and his skills to sponsor others uploads are second to none. He is always willing to help and has a very pleasant attitude. I recommend Andreas at 100%. -- slashd 2017-11-29 12:44:00


Endorsements

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

Robie Basak

General feedback

I sponsored four packages for Andreas in July and August since he joined the Canonical server team in April. Since then, other team members tend to handle his needed sponsorships, but I also generally see his work scroll past. We operate a peer review policy on our team, so he has been doing reviews for existing uploaders also.

I am continually impressed by Andreas' attention to detail and the general comprehensiveness and correctness of his work upon first review. He doesn't just throw a patch at a sponsor to see if it sticks; by the time he requests review, he typically has done far more extensive investigation and testing than I would do before uploading. He mostly asks all necessary questions in public on Freenode before preparing an upload for sponsorship. I've seen him find tangential edge cases and fix those up as well while working a particular bug.

I value Andreas' presence on our team and I'm happy to endorse his application for ~ubuntu-server-dev.

Specific Experiences of working together

Sponsorship miner results: please follow the bug reference through to the MPs to see review comments.

Areas of Improvement

I can't think of anything. Please carry on as you are!


Christian Ehrhardt

General feedback

I sponsored 17 packages of Andreas so far and I'm impressed by his performance and quality. Since in our Team we established a peer review process this goes way beyond the usual ack/nack and instead is a very thorough review and feedback loop. From the early "unsure how to do so" times (he already did great) he evolved quickly into a quality that rarely needs bigger rewrites. I trust in his contributions and they are usually sound and well tested before you get to see them.

Much more you can see his massive improvement and new confidence in the review he provides in our peer review process - he is in that regard an absolutely equal and well qualified member of the server team already, so the application would just complete his ability to contribute.

Specific Experiences of working together

I like that he really loves verify and make things testable in general. No "this looks good in the code, doesn't need test" patches. There always is a good consideration of regressions and test-ability.

Other than that just look at the Sponsorship miner results and the MP reviews.

Also on the SRUs check out the always really well defined SRU templates.

Areas of Improvement

I see him already conquering his subspace of packages and solutions in the server Team where he can excel with his experience and help us most to improve as a Team. So he is already in a great improvement for himself and the Team. I can't think of any cases where I'd recommend that he should do differently.


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:
## http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?
=== Areas of Improvement ===