LandscapeClientPerPackageUploadApplication

I, Andreas Hasenack, apply for upload rights for package landscape-client.

Name

Andreas Hasenack

Launchpad Page

https://launchpad.net/~ahasenack

Wiki Page

https://wiki.ubuntu.com/AndreasHasenack

Who I am

I'm Brazilian and I graduated in Electrical Engineering in 1996. 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, nowadays called 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" this time.

Examples of my work / Things I'm proud of

I created the set of QA requirements (https://wiki.ubuntu.com/LandscapeUpdates) that landscape-client must go through in order to get an SRU exception (https://wiki.ubuntu.com/StableReleaseUpdates#Landscape). Completing those tests is not an easy task, and I knew that when I was writing that document, but I really wanted to be stringent. That results in a test matrix of about 10 common tests per Ubuntu release, and then specific tests for the new features that were added or bugs that were fixed.

I did several SRUs, some more complex than others (dholbach gave me a nice link showing all my sponsored updates).

I think an interesting SRU was the one about bug #1004678. I took the opportunity to clean up a lot the packaging of landscape-client, and that meant reading many documents. It all started with a comment by one of the sponsors about some lintian warnings. I decided to chase them down, and that almost took me into a big rabbit hole, but I took my time and addressed the ones I could, with comments where appropriate (for example, in the overrides file). So, yes, please, keep review comments coming when sponsoring an upload. I also liked the [regression potential] section of that bug, where I discussed what could go wrong. It's hard to predict the future, but raising awareness about the changes helps reviewers not familiar with the package/code.

I also of course enjoy working on much less complex updates/SRUs, like bug #885163 for python-tz, which had a very clear cut error, patch and test case. For this one in particular I even provided a cloud-init config file (in comment 22) for easy verification of the error and the subsequent fix.

The SRU I'm working on now (bug #1053057) is also a very localized bug and the package patch I'm using was only made possible by the work done on the previous SRU where I changed how the package was built. It paid off, by making it much simpler to fix the issue now. You can see that the bug has a test case, long but simple at the same time, and it's what I will use with the packages (again) once they reach proposed.

Another interesting packaging challenge (well, a challenge for my skills anyway) was lp:~landscape/graphite/graphite-landscape-packaging. I needed to build three binary packages out of one big bzr branch (lp:~landscape/graphite/trunk), which is no big deal at first. But upstream was doing three tarball releases, separate source code releases, and had all the code in that one big branch. There was no single build command. Since I wanted to use a recipe, I had to use the branch instead of the released tarballs, and basically to three builds. It was good to learn about overrides in debian/rules, which I used a lot, and splitting of packages.

The graphite recipe is just one of many recipes I wrote to use with Landscape. Most are very simple and straightforward copies from the recipe tutorial. The hardest part is always to figure out how to version the daily build.

Areas of work

In Canonical, I worked mainly in the Landscape team doing QA work, which is very broad. It touches:

  • cloud: using cloud instances for all sorts of tasks, specially SRU tests for landscape-client where I need to test the update in all supported releases of Ubuntu
  • database queries (PostgreSQL). Some examples include searching for computers who have a stuck dpkg process (waiting on a prompt), or for symptoms of a misconfigured proxy (computers reporting installed packages but zero available packages)
  • deployment (Landscape has many different services that can be deployed to different machines behind a load balancer)
  • automatic testing of Landscape with Robot Framework

  • written documentation: Landscape Dedicated Server (LDS) deployment, FAQ (a bit out of date, I'm guilty of that), LDS release notes, API usage and almost all of the "old guides" section at .https://help.landscape.canonical.com.

  • support help for Landscape customers

  • packaging of landscape-client, including automatic daily builds using Launchpad recipes

  • monitoring of the production deployment of Landscape (https://landscape.canonical.com) via log parsing, graphs and assorted performance data

The landscape-client package is a critical piece of Landscape, of course. If the update breaks, computers can't be managed anymore. I take its testing very seriously, so much that it takes days to prepare for an SRU with new features (using the exception), and tests are repeated for all Ubuntu releases we still support (with my own builds first, before asking for the SRU, and then with the builds on -proposed).

Most landscape-client updates are a mix of new features and bug fixes. It's rare for me to do a bug-only fix, but it does happen when time is of the essence and/or the bug is critical (like the recent bug #1053057).

This package is also a bit atypical because it's one source package that builds for several Ubuntu releases. Right now, that's lucid, natty, oneiric, precise and quantal (this work was done by Free Ekanayaka). The debian/rules file is a bit more complicated because of that, as is the control one, but we have been managing so far. The dh_python2 transition broke this a bit in the sense that we can't have conditional build-depends (build dependencies that are conditional on the target Ubuntu release), so the control file is a bit different now between the dh_python2 Ubuntu releases and the others still using python-central or python-support. This is also something that we have to watch for when doing SRUs.

Things I could do better

  • with the knowledge acquired in packaging landscape-client, I could start scanning LP for bugs with patches and build fixed packages for those, proposing SRUs or just uploading to a PPA for others to test
  • automate more of the SRU tests. Some I have no idea how to, like the landscape-sysinfo test, which would be very brittle I think if automated, but others can and would save time. I have helper scripts, but not full automation. What I don't want is to compromise the quality of the tests with the automation. SRUs shouldn't be taken lightly, there is a good reason for that.
  • I have no idea how to use debconf. The debconf bits that landscape-client has were written by somebody else.
  • I should learn more about pre-seeding

Plans for the future

  • simplify the landscape-client as much as possible, given that it has to build on several releases of Ubuntu. I would like to try to use specific overrides in debian/rules where needed
  • learn more about Debian packaging, there are so many cases

General

What I like least in Ubuntu

UDD is a great concept and I love it, but when the "importer" fails the branches lag behind the packages. That's a very complex area and requires profound knowledge of the packaging system and bzr (of the level "I wrote the book about it"), so I don't have good suggestions. If we reversed the process so that the commit would happen first, and then the upload and build would take a branch or a revision and do its thing, that would require everyone to use UDD, which I agree is hard or impractical. But there would be no importer, and all builds would happen from something that was already committed, so it would always be in sync. Like release tarballs and the corresponding source code in some revision control system. You don't release the tarball first, and then import it into bzr: it's the other way around.

I also find the debian/patches story confusing when storing a package in a revision control system like bzr, and I heard the question many times: do we store the code with the patches applied or not? There are pros and cons, and it's flexible enough that some people work one way and others work differently, but that just raises the bar for someone who wants to get started with UDD and is suddenly confronted with "bzr looms" and "pipelines".

I also fear a bit some of the automagic bzr plugins when they detect you are working on a Debian/Ubuntu package. For example, the merge-upstream one where I hit this (surprising to me) behavior: bug #1014802. Another case was "bzr commit" automatically taking the changes to debian/changelog as the commit message by default (which has been fixed I hear).

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.

Daniel Holbach (dholbach)

General feedback

It seems like I sponsored only one change by Andreas, but I was in contact with him a couple of times regarding packaging- or process-related things. My impression was that he was always very cautious and interested in getting it all right.

Juding from his upload history, he has been working on the package for two years, with countless SRUs and bug fixes - I'd definitely trust him to keep the package in good shape.

I also like how he put up the QA requirements for SRUs - which is also understandable for a package mostly used in corporations and other big institutions.

Specific Experiences of working together

ClintByrum

General feedback

I have worked quite a bit with Andreas on Landscape package uploads over the last 2 years. He has been extremely responsive to feedback. Of late his uploads have not needed any changes, as I think he fully understands how the packaging and SRU process especially work.

Specific Experiences of working together

These all went quite well:

https://launchpad.net/ubuntu/+source/landscape-client/12.04-0ubuntu0.12.04.0 https://launchpad.net/ubuntu/+source/landscape-client/11.07.1.1-0ubuntu0.11.04.0 https://launchpad.net/ubuntu/+source/landscape-client/11.07.1.1-0ubuntu0.10.10.0

I cannot recall a time when I had any troubles with Andreas.

Areas of Improvement

The only area to improve on is to gain PPU upload rights for landscape. Smile :)

Dave Walker

General feedback

I've sponsored two uploads, and given pre-review of some others. The quality has always been of good quality, with no firm reason to refuse the upload. I would trust Andreas for this PPU set.

Specific Experiences of working together

I remember clearly a specific example, where Andreas presented me with an upload that was suitable for sponsorship. I made a comment of a slight area of improvement, and Andreas received this well and was eager to try to make as many improvements as possible. It's great to see that he took significant pride in his work.

Areas of Improvement

None related to this. Unrelated, it would be great to see Andreas widen scope, his skills would be welcomed on other packages. Smile :)

Martin Pitt

I only sponsored one set of "new upstream version" SRU uploads:

These went fine, I had nothing to complain about. I do not yet have sufficient experience with Andreas' packaging skills yet to give a recommendation on my own, but I hope this adds another data point. Thanks Andreas! -- -- pitti 2012-10-02 04:33:17

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.''
=== Areas of Improvement ===

CategoryPerPackageUploaderApplication

AndreasHasenack/LandscapeClientPerPackageUploadApplication (last edited 2012-10-02 04:33:17 by pitti)