DeveloperApplication

Differences between revisions 19 and 22 (spanning 3 versions)
⇤ ← Revision 19 as of 2012-10-11 20:30:11 →
Size: 5636
Editor: ua-178
Comment:
← Revision 22 as of 2013-09-19 02:14:58 → ⇥
Size: 2973
Editor: bluesabre
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was copied from UbuntuDevelopment/DeveloperApplicationTemplate
Line 4: Line 5:
----
'''Please do not edit this page. It is a template to be used by people applying as an Ubuntu developer.'''		 '''I, Sean Davis, apply for upload rights for the Xubuntu/Xfce package sets.'''
Line 7: Line 7:
Head over to https://wiki.ubuntu.com/YourName/YourDeveloperApplication instead and make use of this template.
----




'''I, <YOUR NAME>, apply for <universe-contributor|MOTU|core-dev|upload rights for package(s) <X>>.'''

|| '''Name''' || <YOUR NAME> ||
|| '''Launchpad Page''' || <link to your launchpad page> ||
|| '''Wiki Page''' || <link to your Wiki page> ||		 || '''Name''' || Sean Davis ||
|| '''Launchpad Page''' || https://launchpad.net/~smd-seandavis ||
|| '''Wiki Page''' || https://wiki.ubuntu.com/SeanDavis ||
Line 20: Line 12:
''Tell us a bit about yourself.'' I am a software developer from Lexington, KY, USA. I work closely with the Xubuntu team and with upstream Xfce developers to provide the best possible experience in Xubuntu. I also work across teams when the software benefits multiple communities.
Line 23: Line 15:
''Tell us how and when you got involved, what you liked working on and what you could probably do better.'' I started contributing to Xubuntu in 2011, reporting artwork and usability bugs for the various applications in the base Xubuntu installation. I was welcomed into the Xubuntu community where I continued to report bugs. Shortly thereafter, I began fixing bugs, incorporating new features, and even maintaining several of the Xubuntu applications.

After contributing for two years, I finally obtained my Ubuntu membership. Now I am working towards becoming a full-fledged Xubuntu Developer. With direct access to uploads, I hope to ease the burden of packaging on our current developers, and to more quickly provide stability and security updates to our userbase.
Line 28: Line 22:
Non-checkbox areas of work within Ubuntu include [[https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/727416|Ubiquity]] and [[https://code.launchpad.net/~roadmr/ubuntu/natty/casper/709364||Casper]] (that bug resurfaced [[https://bugs.launchpad.net/ubuntu/+source/casper/+bug/809885|here]] and Stéphane Graber was kind enough to squash it). The folks in charge of these projects are always very responsive and patient, which I really appreciate.

Checkbox's situation has changed in the past several months. The Hardware Certification team has been growing in terms of people who can devote time working on Checkbox. This has meant we're much more able to tackle the large bug backlog the project had, while also adding new features and keeping up to date with Ubuntu's evolution. Since a large part of Checkbox are the test scripts, and these need to interact with the kernel and other APIs that keep evolving, they need constant maintenance and updating. Examples that come to mind are the recent migration to UDisks2 (for Ubuntu Quantal), the upgrade to Python3 (Quantal as well), migration to Gtk3 (for Ubuntu 11.10), and changes to APIs for Network Manager.

As a team we've managed to greatly reduce the amount of open and new bugs for [https://bugs.launchpad.net/ubuntu/+source/checkbox/||ubuntu/checkbox]] (Currently 16 open bugs and 2 new ones). Checkbox's trunk/upstream branch still has a large number of open bugs (bug list [[https://bugs.launchpad.net/checkbox/|here]]). However we've drastically reduced the number of open (unlooked-at) ones, and I've been focusing on analyzing open bugs and giving them a clear "statement of work" for developers to work on; this way they can potentially jump straight into coding a solution. I felt this was more conducent to many people working on these triaged bugs, as opposed to i.e. me going over them one-by-one, analyzing, and fixing them. This way developers, both from our team and outside, can work in "parallel" to fix these bugs, and they also don't need to spare brainpower finding a bug to fix.

I've also been trying to tag smaller bugs with "bitesize" to encourage community participation. This has indeed resulted in a few of these bugs being fixed by community members. We've also tried to be extra responsive to contributions to Checkbox from outside the certification team, to further encourage contributions, this has also resulted in more people knowing about checkbox and potentially considering it when searching for a test runner application.

As a result the number of commits per release has grown dramatically, from 30 for the Natty cycle to 217 for the Oneiric cycle, 334 for Precise and 301 for Quantal. Particularly for the Precise cycle, this resulted in our uploads to Ubuntu having very large changelogs, which made reviewers' lives difficult. So for Quantal, despite having slightly less commits and bugfixes, we had a more regular upload cadence, with smaller changesets to ease work for reviewers and sponsors.

Also, in order to ensure our package uploads are sane, we've been ramping up our "unit test" coverage, which also validates that data files contain no errors, that translated versions don't cause crashes, and that the code passes some basic "lint" tests. These processes have already caught a few errors. We complement this with a daily from-trunk PPA build which sends a notification if these automated tests fail, so we can catch these basic problems even if some bogus code makes it into the trunk branch.		 ''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.

I, Sean Davis, apply for upload rights for the Xubuntu/Xfce package sets.

Who I am

I am a software developer from Lexington, KY, USA. I work closely with the Xubuntu team and with upstream Xfce developers to provide the best possible experience in Xubuntu. I also work across teams when the software benefits multiple communities.

My Ubuntu story

I started contributing to Xubuntu in 2011, reporting artwork and usability bugs for the various applications in the base Xubuntu installation. I was welcomed into the Xubuntu community where I continued to report bugs. Shortly thereafter, I began fixing bugs, incorporating new features, and even maintaining several of the Xubuntu applications.

After contributing for two years, I finally obtained my Ubuntu membership. Now I am working towards becoming a full-fledged Xubuntu Developer. With direct access to uploads, I hope to ease the burden of packaging on our current developers, and to more quickly provide stability and security updates to our userbase.

My involvement

Examples of my work / Things I'm proud of

Areas of work

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

Things I could do better

Plans for the future

General

What I like least in Ubuntu

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

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

SeanDavis/DeveloperApplication (last edited 2014-07-01 00:25:26 by logan)