CoreDeveloperApplication

Differences between revisions 1 and 19 (spanning 18 versions)
Revision 1 as of 2013-08-15 17:52:36
Size: 2142
Editor: dannf
Comment:
Revision 19 as of 2014-08-26 22:08:45
Size: 8919
Editor: dannf
Comment:
Deletions are marked like this. Additions are marked like this.
Line 14: Line 14:
''I've been a Debian Developer for ~12 years, and a Canonical employee for ~3 years.'' ''I've been a Debian Developer for 12 years, and a Canonical employee for over 3 years. I like both free software and free beer. I'm experienced working with the kernel, server installer, security issues, autobuilders, packaging, etc.''
Line 17: Line 17:
''Tell us how and when you got involved, what you liked working on and what you could probably do better.'' ''My first real involvement with Ubuntu was in a previous job at HP, probably sometime in 2009. I would resolve hardware support issues (often out of date drivers) with Ubuntu found by our QA team (working w/ Canonical as needed). I also worked directly with HP customers that used Ubuntu to help resolve issues, and packaged up various HP software components for Ubuntu on HP servers. What did I like about it? Helping users resolve real problems. What could I have done better? Actively seek out ProLiant/Ubuntu users to get a macro level view of the issues they were facing. I was otherwise mostly reactive.

My involvement with Ubuntu accelerated in 2010 when I was hired onto the Server OEM team at Canonical. Early on I was mostly working on customer issues througout the server stack (kernel, iSCSI, multipath-tools, etc). I later moved over to the hyperscale team where I found a focus on ARM servers. Lately I've been most notably involved with the arm64 port and related hardware enablement tasks.
Line 21: Line 23:
I'm very much a generalist, though I spend more time in the plumbing than with say desktop applications. When I run into a bug, I try to fix it. Often that is just finding the right patch upstream, backporting it and preparing a patch/merge proposal, but sometimes it involves digging a little deeper.

 * During the devel cycle for 14.04, I did a lot of work on the qemu 1.7 packages to add aarch64 emulation support. The initial qemu-system and qemu-user-static packages were based on backport work I contributed (References: [[https://launchpad.net/ubuntu/+source/qemu/1.7.0+dfsg-2ubuntu6|1]], [[https://launchpad.net/ubuntu/+source/qemu/1.7.0+dfsg-3ubuntu2|2]], [[https://launchpad.net/ubuntu/+source/qemu/1.7.0+dfsg-3ubuntu4|3]], [[https://launchpad.net/ubuntu/+source/qemu/1.7.0+dfsg-3ubuntu5|4]]) which served as the ground work to get libvirt+qemu/kvm and eventually nova compute working in the distribution. This work eventually got replaced prior to 14.04 release by the timely release of QEMU 2.0 - but I still feel the "early access" availability was useful for unblocking developers higher up the stack, as well as providing useful feedback to the upstream project about issues I observed using the software in Ubuntu.
 * I've done a lot of work on the flash-kernel package. Mostly adding support for new platforms, but also some [[https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1328597|work]] on providing an interface for packages and/or admins to drop in u-boot script snippets, and some [[http://anonscm.debian.org/cgit/d-i/flash-kernel.git/commit/?id=6dd3f0e7e5a3462999944e4b60720f418579a615|upstream work]] to add boot argument management, which I'd like to steward into Ubuntu.
 * For debian installer, I contributed the initial arm64 support ([[http://bazaar.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu/revision/1921?start_revid=1998|1]], [[https://code.launchpad.net/~dannf/ubuntu/trusty/base-installer/arm64/+merge/199972|2]]).
 * Lots of minor arm64 port fixes ([[https://code.launchpad.net/~dannf/ubuntu/trusty/partclone/arm64-ftbfs|partclone]], [[https://code.launchpad.net/~dannf/ubuntu/saucy/udisks/lp1235051/+merge/189203|udisks]], [[https://code.launchpad.net/~dannf/ubuntu/trusty/nis/lp1280666|nis]], [[https://code.launchpad.net/~dannf/ubuntu/trusty/cpu-checker/arm64/+merge/207331|cpu-checker]], [[https://code.launchpad.net/~dannf/ubuntu/trusty/numactl/arm64/+merge/207751|numactl]], [[https://launchpad.net/ubuntu/+source/ltrace/0.7.3-4ubuntu4|ltrace]])
 * Fixed a [[https://bugs.launchpad.net/ubuntu/+source/screen/+bug/1213278|build failure in screen]]
 * Found a build failure in procps due to broken functionality in pwdx; identified fixes from upstream and prepared [[https://code.launchpad.net/~dannf/ubuntu/saucy/procps/pwdx-fixes|a fix for Ubuntu]].
 * Found a couple of lshw issues using Ubuntu (discovered while hacking on MAAS on ARM). Triaged and discovered that one was a years-old bug reported in both [[https://bugs.launchpad.net/ubuntu/+source/lshw/+bug/653082|Ubuntu]] and [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525217|Debian]]. The other had not yet been reported. I reported and fixed both of these issues upstream (http://ezix.org/project/ticket/626, http://ezix.org/project/ticket/628), worked with the Debian maintainer to get these fixes uploaded to sid, and finally resolved the bugs in Ubuntu when the package was sync'd.
 * [[https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1053306|LP: #1053306]]: User had an intermittent - but severe - issue with open-iscsi hanging. Root caused, created a simple reproducer, found a fix upstream, backported & got it SRU'd.
 * [[https://bugs.launchpad.net/bugs/1035110|LP: #1035110]] - root caused a MAAS issue with highbank platforms due to a missing driver, identified a fix & got it SRU'd
 * Got a couple of my patches SRU'd so that users could use LTS qemu to emulate highbank ([[https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/1030594|LP: #1030594]], [[https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/1030588|LP: 1030588]])
 * Contributed a [[http://jujucharms.com/charms/precise/qemu-cloud|charm]] that lets you deploy a qemu instance running Ubuntu/armhf onto a public cloud w/ transparent network connectivity.

You can also view a list of packages to which I've contributed here: https://launchpad.net/~dannf/+uploaded-packages.

I try to take an Upstream-first approach though, so a lot of the things I've worked on have come in indirectly e.g. via debian, or kernel.org.
Line 22: Line 42:
''Let us know what you worked on, with which development teams / developers with whom you cooperated and how it worked out.''
## As a per-package uploader, please give us some insight into the package maintenance and bug situation since you're working on it.
''These days I mostly work with the Ubuntu ARM and MAAS teams to add and maintain support for ARM SoCs. I often find myself needing to fix bugs in core packages - often just backporting changes from upstream - and it'd probably be more efficient to do so w/o seeking a sponsor. I also contribute to charms on occasion.''
Line 26: Line 45:
''Keep up with more mailing lists. I suck at following high-traffic lists.''
Line 29: Line 49:
''Continue what I'm doing today (see Areas of work), and work on issues regarding the arm64 port.''
Line 30: Line 52:
''Please describe what you like least in Ubuntu and what thoughts do you have about fixing it.'' ''Unnecessary divergences from upstream. I hope to maintain rigor about pushing things back upstream.''
Line 40: Line 62:
== Serge Hallyn ==

Dann has been a great help behind the scenes with software like multipath-tools and qemu-kvm.

See for instance bug https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/488285 for which he unfortunately frequently gets no credit in the changelog. I wholeheartedly endorse Dann for coredev based on my previous packaging work with him.

== Steve Langasek ==
I have known Dann for over a decade. During that time, as a Debian developer, ia64 porter, and member of the Debian security and kernel teams, he has more than adequately demonstrated mastery of Debian packaging. As a member of the Canonical hyperscale team for the past while, he has also had more than enough opportunity to interact with the Ubuntu community and familiarize himself with Ubuntu-specific policies and practices. Without hesitation, I recommend him to the DMB as a candidate for coredev status.

I, dann frazier, apply for core-dev.

Name

dann frazier

Launchpad Page

https://launchpad.net/~dannf

Wiki Page

https://wiki.ubuntu.com/DannFrazier

Who I am

I've been a Debian Developer for 12 years, and a Canonical employee for over 3 years. I like both free software and free beer. I'm experienced working with the kernel, server installer, security issues, autobuilders, packaging, etc.

My Ubuntu story

My first real involvement with Ubuntu was in a previous job at HP, probably sometime in 2009. I would resolve hardware support issues (often out of date drivers) with Ubuntu found by our QA team (working w/ Canonical as needed). I also worked directly with HP customers that used Ubuntu to help resolve issues, and packaged up various HP software components for Ubuntu on HP servers. What did I like about it? Helping users resolve real problems. What could I have done better? Actively seek out ProLiant/Ubuntu users to get a macro level view of the issues they were facing. I was otherwise mostly reactive.

My involvement with Ubuntu accelerated in 2010 when I was hired onto the Server OEM team at Canonical. Early on I was mostly working on customer issues througout the server stack (kernel, iSCSI, multipath-tools, etc). I later moved over to the hyperscale team where I found a focus on ARM servers. Lately I've been most notably involved with the arm64 port and related hardware enablement tasks.

My involvement

Examples of my work / Things I'm proud of

I'm very much a generalist, though I spend more time in the plumbing than with say desktop applications. When I run into a bug, I try to fix it. Often that is just finding the right patch upstream, backporting it and preparing a patch/merge proposal, but sometimes it involves digging a little deeper.

  • During the devel cycle for 14.04, I did a lot of work on the qemu 1.7 packages to add aarch64 emulation support. The initial qemu-system and qemu-user-static packages were based on backport work I contributed (References: 1, 2, 3, 4) which served as the ground work to get libvirt+qemu/kvm and eventually nova compute working in the distribution. This work eventually got replaced prior to 14.04 release by the timely release of QEMU 2.0 - but I still feel the "early access" availability was useful for unblocking developers higher up the stack, as well as providing useful feedback to the upstream project about issues I observed using the software in Ubuntu.

  • I've done a lot of work on the flash-kernel package. Mostly adding support for new platforms, but also some work on providing an interface for packages and/or admins to drop in u-boot script snippets, and some upstream work to add boot argument management, which I'd like to steward into Ubuntu.

  • For debian installer, I contributed the initial arm64 support (1, 2).

  • Lots of minor arm64 port fixes (partclone, udisks, nis, cpu-checker, numactl, ltrace)

  • Fixed a build failure in screen

  • Found a build failure in procps due to broken functionality in pwdx; identified fixes from upstream and prepared a fix for Ubuntu.

  • Found a couple of lshw issues using Ubuntu (discovered while hacking on MAAS on ARM). Triaged and discovered that one was a years-old bug reported in both Ubuntu and Debian. The other had not yet been reported. I reported and fixed both of these issues upstream (http://ezix.org/project/ticket/626, http://ezix.org/project/ticket/628), worked with the Debian maintainer to get these fixes uploaded to sid, and finally resolved the bugs in Ubuntu when the package was sync'd.

  • LP: #1053306: User had an intermittent - but severe - issue with open-iscsi hanging. Root caused, created a simple reproducer, found a fix upstream, backported & got it SRU'd.

  • LP: #1035110 - root caused a MAAS issue with highbank platforms due to a missing driver, identified a fix & got it SRU'd

  • Got a couple of my patches SRU'd so that users could use LTS qemu to emulate highbank (LP: #1030594, LP: 1030588)

  • Contributed a charm that lets you deploy a qemu instance running Ubuntu/armhf onto a public cloud w/ transparent network connectivity.

You can also view a list of packages to which I've contributed here: https://launchpad.net/~dannf/+uploaded-packages.

I try to take an Upstream-first approach though, so a lot of the things I've worked on have come in indirectly e.g. via debian, or kernel.org.

Areas of work

These days I mostly work with the Ubuntu ARM and MAAS teams to add and maintain support for ARM SoCs. I often find myself needing to fix bugs in core packages - often just backporting changes from upstream - and it'd probably be more efficient to do so w/o seeking a sponsor. I also contribute to charms on occasion.

Things I could do better

Keep up with more mailing lists. I suck at following high-traffic lists.

Plans for the future

General

Continue what I'm doing today (see Areas of work), and work on issues regarding the arm64 port.

What I like least in Ubuntu

Unnecessary divergences from upstream. I hope to maintain rigor about pushing things back upstream.


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.

Serge Hallyn

Dann has been a great help behind the scenes with software like multipath-tools and qemu-kvm.

See for instance bug https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/488285 for which he unfortunately frequently gets no credit in the changelog. I wholeheartedly endorse Dann for coredev based on my previous packaging work with him.

Steve Langasek

I have known Dann for over a decade. During that time, as a Debian developer, ia64 porter, and member of the Debian security and kernel teams, he has more than adequately demonstrated mastery of Debian packaging. As a member of the Canonical hyperscale team for the past while, he has also had more than enough opportunity to interact with the Ubuntu community and familiarize himself with Ubuntu-specific policies and practices. Without hesitation, I recommend him to the DMB as a candidate for coredev status.


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


DannFrazier/CoreDeveloperApplication (last edited 2014-08-26 22:08:45 by dannf)