CoredevApplication

Differences between revisions 48 and 95 (spanning 47 versions)
Revision 48 as of 2018-08-14 18:27:14
Size: 16806
Editor: ahasenack
Comment:
Revision 95 as of 2018-09-23 10:08:31
Size: 24040
Editor: ahasenack
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:



= WORK IN PROGRESS =
Line 29: Line 25:
In December 18th, 2017, I became an Ubuntu Server Developer: https://lists.ubuntu.com/archives/ubuntu-devel/2017-December/040101.html
Line 31: Line 29:
My sponsored uploads: https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=Andreas+Hasenack&sponsoree_search=name

My direct uploads: https://launchpad.net/~ahasenack/+uploaded-packages
Line 32: Line 34:
 * samba ([[https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1696823|#1696823]]):
  * [[https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+ref/samba-extra-dep8-1696823|samba-extra-dep8-1696823]]
  * upstreamed to debian: https://salsa.debian.org/andreas-guest/samba/tree/more-dep8-tests
 * autofs: https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+ref/cosmic-autofs-dep8-1677751
 * krb5 (debian first): https://salsa.debian.org/debian/krb5/merge_requests/2
Samba:
 * [[https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1696823|Bug #1696823]]: samba: extra dep8 tests
 * Branch: [[https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+ref/samba-extra-dep8-1696823|samba-extra-dep8-1696823]]
 * Merged in Debian: https://salsa.debian.org/samba-team/samba/merge_requests/1

Autofs:
 * Merge proposal: https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+merge/347853
 * Pushed to Debian via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901554

krb5:
 * Merged in Debian: https://salsa.debian.org/debian/krb5/merge_requests/2
 * Now in Ubuntu in [[https://launchpad.net/ubuntu/+source/krb5/1.16-2ubuntu1|krb5-1.16-2ubuntu1]], which can be dropped after Debian makes a new release of the package

sssd:
 * MP: https://code.launchpad.net/~ahasenack/ubuntu/+source/sssd/+git/sssd/+merge/355524
 * Bug: [[https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1793882|#1793882]]
Line 41: Line 53:

=== Cooperation with debian and/or upstream===
 * autofs: deb bug, dep8 tests, autofs mailing list about patch, investigation about why the lookup-ldap patch was still necessary (link to ubuntu-devel@ post)
 * samba:
  * dep8 tests: https://salsa.debian.org/samba-team/samba/merge_requests/1
  * https://salsa.debian.org/samba-team/samba/merge_requests/7: Drop deprecated syslog options from default smb.conf
  * https://salsa.debian.org/samba-team/samba/merge_requests/8: logrotate: only try to reload the services if they are running
 * sssd:
  * tests that failed with -Wl,-Bsymbolic-functions enabled (default in ubuntu):
   * https://github.com/SSSD/sssd/pull/632
   * mailing list thread: https://github.com/SSSD/sssd/pull/632
  * https://salsa.debian.org/sssd-team/sssd/merge_requests/1: Create the secrets directory used by sssd-secrets
 * squid4 dep8 fixes pushed to debian:
  * https://salsa.debian.org/squid-team/squid/merge_requests/4
  * https://salsa.debian.org/squid-team/squid/merge_requests/5
 * bind9:
  * https://salsa.debian.org/dns-team/bind/merge_requests/1 I opened it against bind, but it should have been bind9. Debian merged the fix into the right repository.
 * exim4:
  * https://salsa.debian.org/exim-team/exim4/merge_requests/2: Add distro banner (our only delta with Debian). Unfortunately rejected, but we tried.
 * dovecot:
  * https://salsa.debian.org/debian/dovecot/merge_requests/1: More DEP8 tests for Dovecot
 * autofs:
  * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901554: please add dep8 tests (there is no salsa repository yet for autofs)
 * libcloud, which I hit after doing strongswan and paramiko uploads: https://bugs.launchpad.net/ubuntu/+source/libcloud/+bug/1788931
  * fixes were submitted upstream and accepted, last one being https://github.com/apache/libcloud/pull/1237 that will make i386 and armhf tests green as well
  * libcloud tests have been red forever, and were fixed by this upload: https://launchpad.net/ubuntu/+source/libcloud/2.3.0-1ubuntu1
  * fixes submitted upstream: https://github.com/apache/libcloud/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+author%3Apanlinux

=== Cooperation with debian and/or upstream ===
autofs:
 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901554: please add dep8 tests. There is no salsa repository yet for autofs, so I just attached a debdiff.

ocfs2-tools:
 * Pushed up a small DEP8 fix: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905151

Samba:
 * DEP8 tests: https://salsa.debian.org/samba-team/samba/merge_requests/1
 * https://salsa.debian.org/samba-team/samba/merge_requests/7: Drop deprecated syslog options from default smb.conf
 * https://salsa.debian.org/samba-team/samba/merge_requests/8: logrotate: only try to reload the services if they are running

sssd:
 * tests that failed with -Wl,-Bsymbolic-functions enabled (default in ubuntu):
  * mailing list thread: https://github.com/SSSD/sssd/pull/632
  * Resulted in upstream https://github.com/SSSD/sssd/pull/632
 * https://salsa.debian.org/sssd-team/sssd/merge_requests/1: Create the secrets directory used by sssd-secrets
 * DEP8 tests: https://salsa.debian.org/sssd-team/sssd/merge_requests/2

squid4 dep8 fixes pushed to debian. Debian had adopted most of our DEP8 tests previously, but they never passed in their infrastructure (https://ci.debian.net/packages/s/squid/testing/amd64/):
 * https://salsa.debian.org/squid-team/squid/merge_requests/4
 * https://salsa.debian.org/squid-team/squid/merge_requests/5

bind9:
 * https://salsa.debian.org/dns-team/bind/merge_requests/1 I opened it against bind, but it should have been bind9. Debian merged the fix into the right repository.

exim4:
  * https://salsa.debian.org/exim-team/exim4/merge_requests/2: Add distro banner (our only delta with Debian). Unfortunately rejected, but we tried :)

dovecot:
 * https://salsa.debian.org/debian/dovecot/merge_requests/1: More DEP8 tests for Dovecot
Line 66: Line 91:
 * libvirt apparmor bug: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1707400. Apparmor was being called in post without dh_apparmor and how that missed the cached profiles
 * libvirt apparmor bug investigation and SRU: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1707400. Apparmor was being called in post manually, not via dh_apparmor, and that missed the cached profiles. The new profile was never applied.
Line 72: Line 96:
   * https://code.launchpad.net/~ahasenack/ubuntu/+source/ndctl/+git/ndctl    * http://launchpad.net/ubuntu/+source/ndctl
Line 75: Line 99:
   * https://code.launchpad.net/~ahasenack/ubuntu/+source/pmdk/+git/pmdk    * http://launchpad.net/ubuntu/+source/pmdk
Line 82: Line 106:
 * backport that became an sru to bring a new zstd version back into stable releases. *Lots* of testing involved. This included creating a transitional package in bionic.  * backport that became an SRU to bring a new zstd version back into stable releases. *Lots* of testing involved. This included creating a transitional package in bionic.
Line 87: Line 111:
  * apache2 sru with failed dep8 tests in xenial, artful, bionic: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1766186   * A normal apache2 SRU that failed DEP8 in xenial, artful, bionic: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1766186
Line 89: Line 113:
  * new bug filed for libapache2-mod-perl2 dep8 fixes in xenial: https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-perl2/+bug/1779400

 * britney hints MP: https://code.launchpad.net/~ahasenack/britney/ocfs2-tools-hints-1.8.5-5ubuntu1/+merge/351928
  * new bug filed for libapache2-mod-perl2 DEP8 fixes in xenial: https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-perl2/+bug/1779400. Normally we don't do SRUs with only DEP8 fixes, but this package in particular would always fail during an apache2 SRU, which is more common.

 * britney hints MP for ocfs2-tools: https://code.launchpad.net/~ahasenack/britney/ocfs2-tools-hints-1.8.5-5ubuntu1/+merge/351928
Line 95: Line 119:
  * While looking at the reverse dependencies, I missed bind-dyndb-ldap, thinking it was part of bind9, but it's a separate source. Got it sponsored.
  * Then I thought isc-dhcp wasn't needed, because the old bind package with the old soname would still be around. Even tested that scenario, but had to rebuild it as well:
Line 96: Line 122:
bind-dyndb-ldap 11.1-3ubuntu1build1~ppa1 (Newer version available) Andreas Hasenack (2018-07-31)
bind9 1:9.11.4+dfsg-3ubuntu1~ppa2 (Newer version available) Andreas Hasenack (2018-07-30)
debian-installer 20101020ubuntu548~ppa1 (Newer version available) Andreas Hasenack (2018-08-01)
isc-dhcp 4.3.5-3ubuntu8build1~ppa1 (Newer version available) Andreas Hasenack (2018-07-31)
- missed bind-dyndb-ldap in the rdepends output, thinking it was part of bind9, but it's a separate source. Got it sponsored.
- thought isc-dhcp wasn't needed, because the old bind package with the old soname would still be around. Even tested that scenario:
Line 103: Line 123:
  Got it sponsored.
- found out about debian-installer's rdepends via update_output.txt, and asked for a rebuild/sponsorship:
}}}
  * The packages would still not migrate. Looking at the update_output.txt, I found out that debian-installer is a reverse dependency as well. Asked for a rebuild/sponsorship:
{{{
Line 106: Line 127:
  Got it sponsored.

TL;DR rebuilds:
https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.1-3ubuntu2
https://launchpad.net/ubuntu/+source/isc-dhcp/4.3.5-3ubuntu9
https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu548
Line 113: Line 128:


  * Summary of rebuilds needed for bind9 to migrate:
   * https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.1-3ubuntu2
   * https://launchpad.net/ubuntu/+source/isc-dhcp/4.3.5-3ubuntu9
   * https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu548
  * PPA with my test builds: https://launchpad.net/~ahasenack/+archive/ubuntu/bind-merge-9.11.4

 * Bileto usage:
  * I just got access, and used it to run squid-4.x DEP8 tests in all architectures, prior to an actual upload: https://bileto.ubuntu.com/#/ticket/3351. Since then, I used it for other packages, but abandoned the ticket after I was satisfied with the test results, so I don't have a link for them. I just left the squid4 one open for now.

 * New team member mentoring: walked a new team member (kstenerud) through the SRU process using git-ubuntu: https://irclogs.ubuntu.com/2018/08/16/%23ubuntu-server.html#t16:45. We continued the next day on the DEP8 tests topic: https://irclogs.ubuntu.com/2018/08/17/%23ubuntu-server.html#t16:59
Line 120: Line 142:
 * Package maintenance for Conectiva/Mandriva: before Canonical, I was doing server package maintenance for [[https://en.wikipedia.org/wiki/Conectiva|Conectiva]] (which later became [[https://en.wikipedia.org/wiki/Mandriva|Mandriva]]) for 8 years. My focus was authentication, authorization and email servers. I also did a lot of security updates and announcements for Conectiva, you may find them in Bugtraq and other security mailing lists from back then (quick [[https://www.google.com.br/search?q=bugtraq+andreas%40conectiva.com.br|google search]]). For Conectiva, I maintained, among others: MIT kerberos and friends (pam-krb5), openldap and friends (pam-ldap, nss-ldap), cyrus-sasl, cyrus-imapd, postfix, samba.

 * openldap dit: I tried to bring my openldap experience to Ubuntu with a small project called OpenLDAP-DIT (https://launchpad.net/openldap-dit, now recently moved to https://github.com/panlinux/openldap-dit), but it stalled as I was very much involved in Landscape and that had nothing to do with LDAP. I might resume it someday. At one of the Ubuntu UDSs it was even proposed to become the default DIT that Ubuntu would install and setup (https://blueprints.launchpad.net/ubuntu/+spec/server-maverick-openldap-dit).

 * Landscape:
  * Landscape Autopilot: automated cloud deployments (openstack) using juju charms
I think the previous section is a good example of my areas of work. To summarize:
 * DEP8 testing: many fixes for existing DEP8 tests, and new tests that I added
 * upstream contributions: I push changes back to Debian and upstream
 * assorted server packages bug fixing: apache, samba, sssd, kerberos, bind9, squid, and others

From the past:
  * Landscape Autopilot (now discontinued): automated cloud deployments (openstack) using juju charms
Line 127: Line 150:
  * Documentation and release notes: all Landscape release notes, including deployment guides, from https://help.landscape.canonical.com. For example, for the latest release 17.03:   * Documentation and release notes: all Landscape release notes, including deployment guides, from https://help.landscape.canonical.com. For example, for the 17.03 release:
Line 143: Line 166:
## As a per-package uploader, please give us some insight into the package maintenance and bug situation since you're working on it.
Line 146: Line 168:
 * 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.
 * I stopped helping to update the server guide. It still needs work.
 * Create more bug patterns. Experience with triage has showed some patterns in bugs that we can leverage with automation
 * Grouping fixes together in a single upload, since migrations are costly
 * Expand my work to other packages that are in need of maintenance
Line 153: Line 175:
 * Add DEP8 tests to the packages I'm familiar with
 * Help make 18.04 an awesome LTS
 * Make sure LTSs get bug fixes
 * Keep adding DEP8 tests to the Ubuntu and Debian packages, and improve the coverage of existing tests
 * Reduce the delta with Debian by submitting changes to Debian and upstream.
 * Improve the LTS Server Guide in the areas of Authentication, Authorization and Samba
Line 159: Line 182:
 * LTS bugs really pile up :( 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 [[https://bugs.launchpad.net/ubuntu/+source/lighttpd/+bug/1707312/comments/9|#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.''
 * Lack of proper DEP3 headers in patches. This sometimes makes it hard to find out why a patch was introduced, or if it can be dropped. There are lintian checks for this already, but they are not enforced on upload. "What's obvious today, may not be obvious 12 months from now."
 * Many SRU bugs I see being accepted lack what I would call 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.'' We have to reach some sort of balance here. SRUs are already hard for newcomers, but without a proper test procedure, they are also hard on the members of the SRU team.
 * Communication and coordination in `#ubuntu-release` is a bit ''ad-hoc''. One could argue it's agile, since pings from trusted people on IRC can be quickly acted upon, but if you happen to not know who is and isn't around, or by chance hit the channel when people are on holidays or in a sprint, you can be greeted by a black hole. Maybe there could be a vanguard for the week, or the day?
 * Sites, reports, cron jobs, etc, running all over the place, in all types of domain names. Some look more "official" than others. A few examples:
  * http://reqorts.qa.ubuntu.com/reports/
  * https://merges.ubuntu.com/main.html
  * http://iso.qa.ubuntu.com/
  * https://platform-qa-jenkins.ubuntu.com/
  * https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi
  * https://bileto.ubuntu.com/
  * https://people.canonical.com/~ubuntu-archive/pending-sru.html
  * http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
  * https://launchpad.net/ubuntu/bionic/+queue
It feels like someone quickly built a tool to solve an immediate problem, published it under a group account somewhere they had write access to, and that became official because it works and people who need it, know where to find it. I imagine some time ago people thought this would all be part of Launchpad.

 * Packages stuck in proposed-migration for way too long. Sometimes they are syncs, meaning no-one specifically uploaded them, so I guess no-one got notified. But they still take up resources, migration is attempted regularly, new DEP8 tests might be triggered if a dependency is updated, etc.
Line 179: Line 209:
== Christian Ehrhardt ==
=== General feedback ===
I have accompanied Andreas from him joining the server Team - with an already great technical background and emphasis on testing things before pushing changes - to the clearly core-dev material engineer that he is today - where I'm close to create aliases to sponsor his work.
So far I sponsored 45 uploads of Andreas (see [[https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=*hrhardt*&sponsor_search=name&sponsoree=*hasenack*&sponsoree_search=name|sponsor ship miner]]).
I have seen a great progression of quality over time and it reached a a state where I mostly find style suggestions and similar things, but no actual packaging/Ubuntu issues as part of the upload.
I'd judge the quality of his uploads really high and having seen his improvements over the past I'm sure he can adapt to changes as needed. I appreciate that he has grown as much as being a great resource for reviewing my work recently. Due to that he really has my trust and I'm confident he would be a good Ubuntu Core Dev.

=== Specific Experiences of working together ===
Out of recent memory squid4 comes to my mind, where he nicely carried Ubuntu Delta through a Debian source rename. Worked on extended tests, did well on submitting plenty of things to Debian so that Delta stays maintainable and so on ...

Also the rather complex ndctl (new packaging) and libzstd (was a mess on backward/forward compatibility) cases further increased my confidence.

I'm also proud how he took active responsibility of the samba/sssd/ldap area in Ubuntu-server. He combined his former experience with his eagerness to learn and made this somewhat orphaned area great again - great for Ubuntu and great for our team.

=== Areas of Improvement ===
He was part of seed changing activities but not yet driving a lot on his own. There more work could be done to get a better grip of these as well. I'm convinced that he'll do great and not start pushing crazy things on day one.

== Robie Basak ==

Andreas is a colleague of mine on the Canonical server team. According to the sponsorship miner, I've sponsored only 11 separate uploads for Andreas. I'm surprised; I thought it'd be a lot more. We operate a peer review policy on our team. This means that I see his work on a daily basis. I suppose much of what I review of his work he can already upload himself, or other colleagues sponsor.

However we keep hitting uploads that he cannot do without being a core dev. samba and bind9 are a couple of examples.

Much of my endorsement for Andreas' previous successful server packageset application still applies: "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."

Andreas understands well what he doesn't know and is appropriately cautious, asking others before committing to an action to make sure that it is correct. I think his overall knowledge of packaging and Ubuntu processes surpassed the bar for core dev a while ago.

== Nish Aravamudan ==
=== General feedback ===
I have sponsored 19 uploads for Andreas as a former member of the Canonical Ubuntu Server team. In all cases, Andreas demonstrated a commitment to high-quality packaging, even going out of his way to point out potential issues with his changes.

I have no qualms with Andreas being granted core dev rights, based upon his knowledge of Ubuntu processes and packaging.

=== Specific Experiences of working together ===
My sponsorship list is [[https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=*Aravamudan*&sponsor_search=name&sponsoree=*hasenack*&sponsoree_search=name|here]]. While I am no longer working for Canonical, I have sponsored a few things, or reviewed them as a core dev, and Andreas has mantained the same level of high quality work that I experienced as his teammate.

Additionally, Andreas has provided excellent feedback to the git-ubuntu team, both in the form of bugs and in documentation.

=== Areas of Improvement ===
I do not have any specific areas of improvement for Andreas at this time. I do not expect he will overstep any of his bounds, and will continue to ask questions when he is unsure of something in the various workflows that exist.

== Steve Langasek ==
=== General feedback ===
I have known of Andreas Hasenack's work since Mandriva times two decades ago. I am unsurprised that the upload which I sponsored for him was straightforwardly correct and required no iteration. I also did NEW processing of the new packages ndctl and pmdk which he prepared on behalf of the Ubuntu Server Team, and which were impeccably handled, requiring only a corner-case discussion of copyright file handling when no copyright holder is listed. I have no reservations about recommending him for core-dev, despite the relatively narrow interactions I've had with him directly on Ubuntu packaging.

I, Andreas Hasenack, apply for Ubuntu Core 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.

In December 18th, 2017, I became an Ubuntu Server Developer: https://lists.ubuntu.com/archives/ubuntu-devel/2017-December/040101.html

Examples of my work / Things I'm proud of

My sponsored uploads: https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=Andreas+Hasenack&sponsoree_search=name

My direct uploads: https://launchpad.net/~ahasenack/+uploaded-packages

DEP8 tests I added

Samba:

Autofs:

krb5:

sssd:

FTBFS fixes I uploaded

Cooperation with debian and/or upstream

autofs:

ocfs2-tools:

Samba:

sssd:

squid4 dep8 fixes pushed to debian. Debian had adopted most of our DEP8 tests previously, but they never passed in their infrastructure (https://ci.debian.net/packages/s/squid/testing/amd64/):

bind9:

exim4:

dovecot:

Misc

  jul 31 15:44:10 <ahasenack>     and upgrading just bind, leaving isc-dhcp without a rebuild, also works: https://pastebin.ubuntu.com/p/zkw8nzryYV/
  • The packages would still not migrate. Looking at the update_output.txt, I found out that debian-installer is a reverse dependency as well. Asked for a rebuild/sponsorship:

  ago 01 14:37:54 <ahasenack>     hi, my bind9 upload, which bumped the soname, also needs a debian-installer rebuild (ppa at https://launchpad.net/~ahasenack/+archive/ubuntu/bind-merge-9.11.4/+packages). Would someone sponsor this for me? https://pastebin.ubuntu.com/p/HPVtSzkPK7/

Areas of work

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

I think the previous section is a good example of my areas of work. To summarize:

  • DEP8 testing: many fixes for existing DEP8 tests, and new tests that I added
  • upstream contributions: I push changes back to Debian and upstream
  • assorted server packages bug fixing: apache, samba, sssd, kerberos, bind9, squid, and others

From the past:

  • Ubuntu Server Guide documentation fixes:
    • #1692259: slapd service does not automatically start

    • #973981: Ubuntu 11.10 help page for kerberos and ldap uses deprecated commands

    • #1038625: kerberos: never states to create non-admin user principal

    • #1170876: LDAP Private Key Access

    • #1239914: ldap installation Server guide implies for default settings that do not happen

    • #1409392: 'Kerberos and LDAP' instructions show bad ldap_kerberos_container_dn example

    • #1579209: Samba and LDAP is completely out of date

    • #1603540: wrong ldif file for altering indexes

Things I could do better

  • I stopped helping to update the server guide. It still needs work.
  • Create more bug patterns. Experience with triage has showed some patterns in bugs that we can leverage with automation
  • Grouping fixes together in a single upload, since migrations are costly
  • Expand my work to other packages that are in need of maintenance

Plans for the future

General

  • Keep adding DEP8 tests to the Ubuntu and Debian packages, and improve the coverage of existing tests
  • Reduce the delta with Debian by submitting changes to Debian and upstream.
  • Improve the LTS Server Guide in the areas of Authentication, Authorization and Samba

What I like least in Ubuntu

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

It feels like someone quickly built a tool to solve an immediate problem, published it under a group account somewhere they had write access to, and that became official because it works and people who need it, know where to find it. I imagine some time ago people thought this would all be part of Launchpad.

  • Packages stuck in proposed-migration for way too long. Sometimes they are syncs, meaning no-one specifically uploaded them, so I guess no-one got notified. But they still take up resources, migration is attempted regularly, new DEP8 tests might be triggered if a dependency is updated, etc.


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.

Christian Ehrhardt

General feedback

I have accompanied Andreas from him joining the server Team - with an already great technical background and emphasis on testing things before pushing changes - to the clearly core-dev material engineer that he is today - where I'm close to create aliases to sponsor his work. So far I sponsored 45 uploads of Andreas (see sponsor ship miner). I have seen a great progression of quality over time and it reached a a state where I mostly find style suggestions and similar things, but no actual packaging/Ubuntu issues as part of the upload. I'd judge the quality of his uploads really high and having seen his improvements over the past I'm sure he can adapt to changes as needed. I appreciate that he has grown as much as being a great resource for reviewing my work recently. Due to that he really has my trust and I'm confident he would be a good Ubuntu Core Dev.

Specific Experiences of working together

Out of recent memory squid4 comes to my mind, where he nicely carried Ubuntu Delta through a Debian source rename. Worked on extended tests, did well on submitting plenty of things to Debian so that Delta stays maintainable and so on ...

Also the rather complex ndctl (new packaging) and libzstd (was a mess on backward/forward compatibility) cases further increased my confidence.

I'm also proud how he took active responsibility of the samba/sssd/ldap area in Ubuntu-server. He combined his former experience with his eagerness to learn and made this somewhat orphaned area great again - great for Ubuntu and great for our team.

Areas of Improvement

He was part of seed changing activities but not yet driving a lot on his own. There more work could be done to get a better grip of these as well. I'm convinced that he'll do great and not start pushing crazy things on day one.

Robie Basak

Andreas is a colleague of mine on the Canonical server team. According to the sponsorship miner, I've sponsored only 11 separate uploads for Andreas. I'm surprised; I thought it'd be a lot more. We operate a peer review policy on our team. This means that I see his work on a daily basis. I suppose much of what I review of his work he can already upload himself, or other colleagues sponsor.

However we keep hitting uploads that he cannot do without being a core dev. samba and bind9 are a couple of examples.

Much of my endorsement for Andreas' previous successful server packageset application still applies: "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."

Andreas understands well what he doesn't know and is appropriately cautious, asking others before committing to an action to make sure that it is correct. I think his overall knowledge of packaging and Ubuntu processes surpassed the bar for core dev a while ago.

Nish Aravamudan

General feedback

I have sponsored 19 uploads for Andreas as a former member of the Canonical Ubuntu Server team. In all cases, Andreas demonstrated a commitment to high-quality packaging, even going out of his way to point out potential issues with his changes.

I have no qualms with Andreas being granted core dev rights, based upon his knowledge of Ubuntu processes and packaging.

Specific Experiences of working together

My sponsorship list is here. While I am no longer working for Canonical, I have sponsored a few things, or reviewed them as a core dev, and Andreas has mantained the same level of high quality work that I experienced as his teammate.

Additionally, Andreas has provided excellent feedback to the git-ubuntu team, both in the form of bugs and in documentation.

Areas of Improvement

I do not have any specific areas of improvement for Andreas at this time. I do not expect he will overstep any of his bounds, and will continue to ask questions when he is unsure of something in the various workflows that exist.

Steve Langasek

General feedback

I have known of Andreas Hasenack's work since Mandriva times two decades ago. I am unsurprised that the upload which I sponsored for him was straightforwardly correct and required no iteration. I also did NEW processing of the new packages ndctl and pmdk which he prepared on behalf of the Ubuntu Server Team, and which were impeccably handled, requiring only a corner-case discussion of copyright file handling when no copyright holder is listed. I have no reservations about recommending him for core-dev, despite the relatively narrow interactions I've had with him directly on Ubuntu packaging.

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


AndreasHasenack/CoredevApplication (last edited 2018-09-23 10:08:31 by ahasenack)