DeveloperApplication

Differences between revisions 18 and 19
Revision 18 as of 2011-08-27 04:40:55
Size: 2373
Editor: brian-murray
Comment:
Revision 19 as of 2012-10-11 20:30:11
Size: 5636
Editor: ua-178
Comment:
Deletions are marked like this. Additions are marked like this.
Line 28: Line 28:
''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.
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.


Please do not edit this page. It is a template to be used by people applying as an Ubuntu developer.

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>

Who I am

Tell us a bit about yourself.

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

Examples of my work / Things I'm proud of

Areas of work

Non-checkbox areas of work within Ubuntu include Ubiquity and https://code.launchpad.net/~roadmr/ubuntu/natty/casper/709364 (that bug resurfaced 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 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.

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)