PerPackageDeveloperApplication

Differences between revisions 1 and 2
Revision 1 as of 2010-12-16 17:14:10
Size: 2318
Editor: m4f5636d0
Comment:
Revision 2 as of 2010-12-16 22:57:41
Size: 3871
Editor: m345636d0
Comment:
Deletions are marked like this. Additions are marked like this.
Line 19: Line 19:
''Tell us how and when you got involved, what you liked working on and what you could probably do better.'' 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
maintain 'daily' (more like weekly) builds of kvm and libvirt, and
have proposed uploads for kvm, libvirt, vmbuilder, and initramfs-tools
both for bug fixes and for merges.
Line 23: Line 32:

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.
Line 24: Line 40:
''Let us know what you worked on, with which development teams / developers 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.
I work a lot in the virtualization stack. I'm also developing some
kernel features in support of more useful containerization. And I
also work with some of the multipath storage stack, where there are
still open bugs in multipath-tools, initramfs-tools, and grub.
Line 29: Line 47:
The smallest bugfix can lead to a great deal of follow-up work
in terms of many SRUs plus pushes to debian and/or upstream.
The process sometimes is daunting to me, and I could stand to
get better at doing such things without having to re-read the
guides in the wiki 10 times for each attempt.
Line 31: Line 55:

Contribute to maintaining the virtualization stack, and work to
make containers a first-class citizen in that sphere.
Line 32: Line 60:
''Please describe what you like least in Ubuntu and what thoughts do you have about fixing it.''
Sometimes packages get ubuntu-specific patches, without the
requisite followup. As a result, the packages don't get
further syncs from debian. The result can be hard to straighten
out, particularly when there are debian/changelog entries listing
10 or 20 'little' changes, each of which must be checked against
the new upstream to see if they've been applied there or are still
relevant. (But really, that's a result of process not having
been properly followed in the first place.)


I, Serge Hallyn, apply for upload rights for packages vmbuilder and multipath-tools.

Name

Serge Hallyn

Launchpad Page

https://launchpad.net/~serge-hallyn

Wiki Page

http://wiki.ubuntu.com/SergeHallyn

Who I am

I'm a member of the server team, most active in the virtualization stack and, recently, enterprise storage stack. I've been maintaining the KVM and libvirt packages, and recently took over the vmbuilder 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 maintain 'daily' (more like weekly) builds of kvm and libvirt, and have proposed uploads for kvm, libvirt, vmbuilder, and initramfs-tools both for bug fixes and for merges.

My involvement

Examples of my work / Things I'm proud of

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.

Areas of work

I work a lot in the virtualization stack. I'm also developing some kernel features in support of more useful containerization. And I also work with some of the multipath storage stack, where there are still open bugs in multipath-tools, initramfs-tools, and grub.

Things I could do better

The smallest bugfix can lead to a great deal of follow-up work in terms of many SRUs plus pushes to debian and/or upstream. The process sometimes is daunting to me, and I could stand to get better at doing such things without having to re-read the guides in the wiki 10 times for each attempt.

Plans for the future

General

Contribute to maintaining the virtualization stack, and work to make containers a first-class citizen in that sphere.

What I like least in Ubuntu

Sometimes packages get ubuntu-specific patches, without the requisite followup. As a result, the packages don't get further syncs from debian. The result can be hard to straighten out, particularly when there are debian/changelog entries listing 10 or 20 'little' changes, each of which must be checked against the new upstream to see if they've been applied there or are still relevant. (But really, that's a result of process not having been properly followed in the first place.)


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.


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


SergeHallyn/PerPackageDeveloperApplication (last edited 2011-02-17 17:31:14 by cpe-70-123-141-2)