MOTUApp

Differences between revisions 3 and 6 (spanning 3 versions)
Revision 3 as of 2010-03-14 21:42:14
Size: 5068
Editor: pool-173-79-171-170
Comment: add wiki plug
Revision 6 as of 2010-04-06 15:40:04
Size: 5970
Editor: 158
Comment:
Deletions are marked like this. Additions are marked like this.
Line 23: Line 23:
In the most recent development cycle, I handled the migration of `autokey`, a GTK text replacement utility, to the packages `autokey-common` and `autokey-gtk`, allowing users to also choose `autokey-kde` if they so choosed. The split was particularly complicated, since they were all in one Python package, and the `-gtk`, `-qt` versions both depended on a daemon from `-common`. In the most recent development cycle, I handled the migration of `autokey`, a GTK text replacement utility, to the packages `autokey-common` and `autokey-gtk`, allowing users to also choose `autokey-kde` if they so choosed. The split was particularly complicated, since they were all in one Python package, and the `-gtk`, `-qt` versions both depended on a daemon from `-common`. In Debian, we wanted users to transition to the `-qt` package, but I was hesiatant to introduce an Ubuntu delta just to change a dependency. After some debugging on `#ubuntu-motu` and the exposure of my lack of make-fu, I managed to have the dependency be chosen based on which distribution the package was built for.
Line 27: Line 27:
I also packaged `groundcontrol`, a distributed-development plugin for Nautilus, and was able to identify several bugs that we were able to squash before it was included in Lucid.
A number of my uploaded packages are syncs to fix items on the [[http://qa.ubuntuwire.org/bugs/rcbugs/lucid/|RC fixes not currently in Ubuntu]] list. The process involves a local build, a reading of the upstream changelog, testing, and verification that they do not introduce any new features.

I also packaged `groundcontrol`, a Launchpad/bzr plugin for Nautilus, and was able to identify several bugs that we were able to squash before it was included in Lucid.
Line 55: Line 58:
Luke has been a huge help to our efforts to promote the use of Ubuntu in education within Arlington Public Schools. His packaging of gasp alone has been invaluable. Having Luke as a MOTU will speed the process of getting our educational software shared with the community. -- JeffreyElkner

I, Luke Faraone, apply for MOTU.

Name

Luke Faraone

Launchpad Page

https://launchpad.net/~lfaraone

Wiki Page

https://wiki.ubuntu.com/LukeFaraone

Who I am

I'm a high school Junior in Arlington, Virginia. In addition to my work in Ubuntu and Debian, I am a contributor to the One Laptop per Child and Sugar Labs projects. I have also been an administrtator on the English Wikipedia since 2008.

When I graduate, I plan to major in Computer Science or Computer Engineering.

My Ubuntu story

I've been working with Ubuntu for four years, and contributing in a technical capacity for two. At first, I helped primarily through advocacy, but in 2008 I moved towards packaging. What interested me most about Ubuntu was the democracy of it: anybody can contribute a fix, and, after a review by a sponsor, have it make the next release of Ubuntu. I submitted my first debdiffs in late 2008, which were all kindly sponsored by JamesWestby.

At my school, I use and administer Ubuntu every day in our Computer Science lab, which is powered by LTSP with over 30 clients.

My involvement

My first package was python-gasp, which I now maintain in Debian. I've spent some time working on miscellaneous fixes to the variety Ubuntu Sugar packages, and worked with upstream to integrate fixes in a timely manner.

When I have free time, I do some bug triage; I'm a member of Ubuntu BugControl.

Examples of my work / Things I'm proud of

In the most recent development cycle, I handled the migration of autokey, a GTK text replacement utility, to the packages autokey-common and autokey-gtk, allowing users to also choose autokey-kde if they so choosed. The split was particularly complicated, since they were all in one Python package, and the -gtk, -qt versions both depended on a daemon from -common. In Debian, we wanted users to transition to the -qt package, but I was hesiatant to introduce an Ubuntu delta just to change a dependency. After some debugging on #ubuntu-motu and the exposure of my lack of make-fu, I managed to have the dependency be chosen based on which distribution the package was built for.

I also submitted an SRU for a locale-dependent crashing bug, and coordinated a security fix for a data corruption / local denial of service vulnerability across Debian, Ubuntu, and upstream.

A number of my uploaded packages are syncs to fix items on the RC fixes not currently in Ubuntu list. The process involves a local build, a reading of the upstream changelog, testing, and verification that they do not introduce any new features.

I also packaged groundcontrol, a Launchpad/bzr plugin for Nautilus, and was able to identify several bugs that we were able to squash before it was included in Lucid.

Areas of work

I try to push my changes through Debian whenever possible, so that it can benefit all distributions. On Ubuntu, I usually interact with the release team and Archive Administrators after the various freezes, when I need approval to get my work synced.

When I worked with the SugarTeam, I collaborated with MorganCollett and JamesWestby on fixing broken Sugar packages imported from Debian, along with some from earlier (divergent) Ubuntu releases.

I work to eliminate the low-hanging, but often monotonous/time-consuming fruit, so that the more difficult tasks can be tackled by people brighter than I.

Things I could do better

Often, my work slips past the Ubuntu release schedule; in the future I should work towards fixing things sooner rather than waiting for the proverbial "last minute".

Plans for the future

General

When I get more free time, I hope to become more involved with the Ubuntu Sugar team, which I have been busy for lately.

I'm also interested in adding more applications I find useful to Ubuntu, as well as lowering the barrier to entry for packages with predictable structure (for example: DocBook documentation) into Ubuntu.

What I like least in Ubuntu

The visual and user-visible distinction between KDE and GNOME application is greater than I would like. Ideally, we should implement themes on the desktop that allow each to look "native" in each others' environment, since people often mix and match based on which accomplishes the task best, not which toolkit they come from.

What I like most in Ubuntu

I'm excited about the work being done to applying DistributedDevelopment to Ubuntu packages, through the work on bzr-builddeb and opportunistic-developer-enabling software like groundcontrol.


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@.

Luke has been a huge help to our efforts to promote the use of Ubuntu in education within Arlington Public Schools. His packaging of gasp alone has been invaluable. Having Luke as a MOTU will speed the process of getting our educational software shared with the community. -- JeffreyElkner


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


CategoryMOTUApplication

LukeFaraone/MOTUApp (last edited 2010-04-27 14:59:35 by 158)