I, Serge Hallyn, apply for upload rights for the Ubuntu Server package set.
Who I am
I live in the US. I did graduate school at William and Mary in Virginia, where I first got involved in linux kernel hacking and DTE (aka TE as in selinux). While a graduate student, I was also sysadmin for a myriad of platforms including linux. I spent a year in Dresden working for Scionics doing programming in python, before joining IBM's linux technology center. Last year, I moved to Canonical.
I'm a member of the ubuntu server team, most active in the virtualization stack and, recently, enterprise storage stack. I've been maintaining the KVM and libvirt packages and active in the LXC package.
My Ubuntu story
I started using Ubuntu after years of gentoo, when I received a new work laptop and needed to have it up very quickly. Ever since, I've appreciated the quick installs, quick upgrades, and, for machines with little interaction, the stability and low rate of updates for LTS releases.
I got involved with Ubuntu development when I joined Canonical. I have upload rights to some of the packages I'm most involved in, like qemu-kvm, libvirt, and multipath-tools. However people are getting tired my asking them to sponsor uploads for other packages like lxc.
Examples of my work / Things I'm proud of
I've been very active in packaging (both for devel and SRUs) for libvirt, qemu-kvm, multipath-tools, and lxc. I've worked with debian to push bugfixes for vsftpd, setools, and initramfs-tools.
http://pad.lv/350936 - libvirt shutdown - proposed tree for merge
http://pad.lv/753308 - lxc autostart
http://pad.lv/814222 - qemu-kvm convert 127G - sent patch upstream
http://pad.lv/660597 - multipath-tools SRU
http://pad.lv/644489 (multipath-tools) pushed SRU for ppetraki
http://pad.lv/794202 - libcap on large files - submitted debian bug with debdiff
http://pad.lv/786941 kvm lucid boot -n
http://pad.lv/784888 - vmbuilder partition files with <3 args.
http://pad.lv/582769 (libcap -lpam) - forwarded to debian
http://pad.lv/747090 (qemu-kvm INT)
http://pad.lv/771227 - virsh save doesn't restore right (kernel from INT bug works for me)
http://pad.lv/697046 - libvirt build-depend on parted - do SRU
http://pad.lv/280421 and 777193 - ethtool to /sbin - pushed fix and SRU for lucid
http://pad.lv/693594 - libcgroup shouldn't move kernel threads to cgroups
http://pad.lv/769025 - libcgroup fails purge - fixed in cgconfig.conf post-script
http://pad.lv/726099 - libvirt crashes - move nodeDeviceLock higher into callers?
http://pad.lv/574665 - qemu-kvm lucid 1Tb write - pushed fix to lucid-proposed
http://pad.lv/644669 - libcgroup upstart, start before libvirt
http://pad.lv/697676 (ntp tick) - forwarded to debian
- make multipath-tools-boot version with modified upstart script - forwarded to debian
Areas of work
Packaged kvm for lucid, maverick, and natty. Packaged libvirt for natty. Recently merged vmbuilder fixes and proposed new uploads. Pushed casper fix to deal more gracefully with mount failures. Worked with debian to push bugfixes for vfstpd, setools, and initramfs-tools.
I've been particularly active in lxc, where I'm contributing to the kernel, upstream lxc, debian packages, and of course the ubuntu packages.
Things I could do better
I want to get more involved with debian packaging. I do try to send patches to debian maintainers when I find relevant bugs, but I still feel uneasy when doing it, so I may like to get more involved in non-bugfix packaging for debian packages.
Plans for the future
I know I've still got plenty to learn about packaging. I intend to do more syncs and merges on non-server packages to build up my experience in preparation for coredev membership.
What I like least in Ubuntu
I love Ubuntu
Sometimes it can be frustrating to figure out precisely what fixed a specific bug, especially when the corresponding UDD tree has stopped syncing and the changelog entry is overly vague. My hope is that UDD - and especially the auto-syncing of uploads - will keep getting better to help address this. When I sponsor packages, I will push for changelog entries that make future guessing (when a bug crops back up, or when syncing) unnecessary.
If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.
Having seen the contributions to the Ubuntu kernel as well as to upstream kernel work, I am confident that Serge shows the right skill and care to become a package uploader.
-- stefan-bader-canonical 2011-10-20 10:02:39
Serge is methodical and thoughtful. Giving him direct upload access would only be a benefit to Ubuntu. If we don't give him upload access, he'll just keep making more PPAs! -- kees 2011-11-02 20:37:59
I trust Serge's uploads implicitly. He's an outstanding upstream developer, Ubuntu packager, community member, and colleague. Serge absolutely deserves Ubuntu upload rights.
Specific examples of working together
Wow, I've known Serge for almost 6 years, having worked at both Canonical and IBM together. We've teamed on lots of work in both places, much of it around eCryptfs, SELinux, Linux security and encryption, KVM, libvirt, and much of the virtualization stack in Ubuntu. Serge's work is consistently outstanding.
I have been reviewing and sponsoring quite a few uploads from Serge over the last year or so. Mostly related to his work on LXC and the cgroup package. I don't remember ever having to update anything in his changes before uploading. Most of these were also so good that they could just be pushed as SRU without any modification (well targeted and limited changes with easy to read/understand diffs). I think it's more than time for Serge to finally be able to upload by himself
Specific Experiences of working together
I've mostly been working with Serge on LXC. He's very active on both the Ubuntu side of LXC (packaging, merging changes from Debian, bug triaging, ...) and upstream side of things. LXC is a very actively maintained package with a good relationship with Debian and upstream. Most patches are forwarded upstream before they even get uploaded to Ubuntu.
Serge is methodical and careful in his work. He is thorough when investigating bugs and proposing fixes. I've not seen a single example of Serge taking a quick and easy way out.
Specific Experiences of working together
I've worked with [nagged] Serge extensively over libvirt and lxc. His expertise in lxc has forced him to basically maintain the lxc code in libvirt for us. He's responsive and has fixed numerous bugs, working with Ubuntu and libvirt upstream to correctly get issues resolved.
== <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 ===