MOTUApplication

Differences between revisions 14 and 15
Revision 14 as of 2009-05-06 07:12:41
Size: 6555
Editor: i59F77CD4
Comment:
Revision 15 as of 2009-05-08 18:45:15
Size: 7697
Editor: cpe-72-229-211-120
Comment:
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
''Tell us a bit about yourself.''
I'm a graduate student in Urban Affairs at Hunter College in New York City.
Line 16: Line 17:
I'd tried various Linux distributions in the past, but didn't become a full time Linux user until installing Feisty. While the nature of Free Software was appealing to me, it was really the great community around Ubuntu that got me hooked. Looking for ways to give back I became involved with bug triaging during the Gutsy cycle and soon noticed things that I could fix myself. My first uploads were during the Hardy cycle, and I've steadily grown more involved with 50+ uploads in the Jaunty cycle according to http://thc.emgent.org/utu/utu_jaunty.php
Line 17: Line 19:
I think it's time for me to take the next step...
Line 26: Line 29:
In my upload of evolution 2.25.91 I split out the documentation into separate locales. It's probably one of my most complicated uploads: In my upload of evolution 2.25.91 I split out the documentation into separate locales. It's probably one of my more complicated uploads:
Line 34: Line 37:
Most of my work probably falls into the category of low hanging fruit. In my work triaging bugs I often come across things with simple fixes that just haven't seen any attention from a developer. While not the hardest work technically speaking, I think it is very important. If for no other reason, users are very often frustrated by such bugs. Especially in cases where someone has taken the time to file a bug and even find a solution, but just doesn't understand Ubuntu processes (i.e. turn their work around into a patch, create a debdiff, or even just know what team needs to be subscribed). So in general, I'm interested in getting Universe into a better state. Something which I suppose must be a good quality in a MOTU. Most of my work probably falls into the category of low hanging fruit. In my work triaging bugs I often come across things with simple fixes that just haven't seen any attention from a developer. While not the hardest work technically speaking, I think it is very important. If for no other reason, users are very often frustrated by such bugs. Especially in cases where someone has taken the time to file a bug and even find a solution, but just doesn't understand Ubuntu processes (i.e. turn their work around into a patch, create a debdiff, or even just know what team needs to be subscribed). To this end, I've become involved with the new [[Packaging/Training]] sessions. So in general, I'm interested in getting Universe into a better state. Something which I suppose must be a good quality in a MOTU.
Line 38: Line 41:
One package I've worked on quite a bit during Jaunty was [[https://edge.launchpad.net/ubuntu/+source/deluge |deluge]] (and the related [[https://edge.launchpad.net/ubuntu/+source/libtorrent-rasterbar |libtorrent-rasterbar]] and [[https://edge.launchpad.net/ubuntu/+source/qbittorrent| qbittorent]] packages). Doing so I have built a working relationship with the Debian maintainer. I was able to turn our out-dated version into a sync until the python 2.6 transition which I handled (patch submitted to Debian). I've handled the merges since that point. I'm glad to say that Jaunty will ship with the most resent version. One package I've worked on quite a bit during Jaunty was [[https://edge.launchpad.net/ubuntu/+source/deluge |deluge]] (and the related [[https://edge.launchpad.net/ubuntu/+source/libtorrent-rasterbar |libtorrent-rasterbar]] and [[https://edge.launchpad.net/ubuntu/+source/qbittorrent| qbittorent]] packages). Doing so I have built a working relationship with the Debian maintainer. I was able to turn our out-dated version into a sync until the python 2.6 transition which I handled (patch submitted to Debian). I've handled the merges since that point. I'm glad to say that Jaunty shipped with the most recent version at the time.
Line 44: Line 47:

Generally, more testing before uploading is always a good thing. At least in one case (the Elisa python transition) in the Jaunty cycle, I test built a package successfully then made another change. I submitted the debdiff without rebuilding, assuming that it was fine when it was actually FTBFS. My sponsor caught it, but it should have never got submitted with out building it in the first place.

I, Andrew Starr-Bochicchio, apply for MOTU.

Who I am

I'm a graduate student in Urban Affairs at Hunter College in New York City.

My Ubuntu story

I'd tried various Linux distributions in the past, but didn't become a full time Linux user until installing Feisty. While the nature of Free Software was appealing to me, it was really the great community around Ubuntu that got me hooked. Looking for ways to give back I became involved with bug triaging during the Gutsy cycle and soon noticed things that I could fix myself. My first uploads were during the Hardy cycle, and I've steadily grown more involved with 50+ uploads in the Jaunty cycle according to http://thc.emgent.org/utu/utu_jaunty.php

I think it's time for me to take the next step...

My involvement

Examples of my work / Things I'm proud of

Well, I suppose I'd be most proud of the three packages that I maintain directly in Debian: parcellite, file-browser-applet, and ttf-rufscript.

In my upload of evolution 2.25.91 I split out the documentation into separate locales. It's probably one of my more complicated uploads:

https://bugs.launchpad.net/bugs/330340

I've also done a number of security and SRU uploads, showing that I have a good understanding of Ubuntu processes.

Areas of work

Most of my work probably falls into the category of low hanging fruit. In my work triaging bugs I often come across things with simple fixes that just haven't seen any attention from a developer. While not the hardest work technically speaking, I think it is very important. If for no other reason, users are very often frustrated by such bugs. Especially in cases where someone has taken the time to file a bug and even find a solution, but just doesn't understand Ubuntu processes (i.e. turn their work around into a patch, create a debdiff, or even just know what team needs to be subscribed). To this end, I've become involved with the new Packaging/Training sessions. So in general, I'm interested in getting Universe into a better state. Something which I suppose must be a good quality in a MOTU.

As a GNOME user, I'm of course interested in the Ubuntu desktop, and have done some work in main with the desktop team. (See the "What I like least in Ubuntu" for some difficulties I've had here.)

One package I've worked on quite a bit during Jaunty was deluge (and the related libtorrent-rasterbar and qbittorent packages). Doing so I have built a working relationship with the Debian maintainer. I was able to turn our out-dated version into a sync until the python 2.6 transition which I handled (patch submitted to Debian). I've handled the merges since that point. I'm glad to say that Jaunty shipped with the most recent version at the time.

More recently, I've been getting involved with the artwork team. I'm not an artist, but I am generally interested in having beautiful GNOME desktop choices for our users. I noticed that one of the things that the artwork team lacks are people familiar with packaging and Ubuntu processes in general. I've worked on both the gnome-themes-ubuntu and community-themes packages. Becoming a MOTU will be helpful with this work (the community-themes package in particular) as there aren't any MOTUs active in the team. I'm also preparing GNOME-Colors and Shiki-Colors packages for Debian with the goal of having them synced into Karmic.

Things I could do better

Generally, more testing before uploading is always a good thing. At least in one case (the Elisa python transition) in the Jaunty cycle, I test built a package successfully then made another change. I submitted the debdiff without rebuilding, assuming that it was fine when it was actually FTBFS. My sponsor caught it, but it should have never got submitted with out building it in the first place.

Plans for the future

General

As a contributor, I've benefited greatly from the activity of the Universe Sponsors. With 50+ uploads during the Jaunty cycle, I feel that I owe the Sponsors team a lot of work if I become a MOTU. This fits well with my general goals of helping new contributors learn Ubuntu processes and helping to pick off some of the low hanging fruit.

What I like least in Ubuntu

One issue I face constantly is the problem of IRC. While I appreciate its usefulness and the importance of real time communication, I'm not capable of idling in IRC channels all day. I feel that in some ways it is very hard to connect with the Ubuntu developer community if you are not very active in IRC. For instance, I feel that I could be much more useful for the desktop-team than I have been, but assignments are mostly dealt with through the IRC channel.

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.

Daniel Holbach (dholbach)

General feedback

It's been an absolute pleasure working with Andrew. He has been quick to learn, quick to iron out small issues and a huge asset to the team. I'd say I sponsored 15-20 packages of his and I've been very happy with the quality. I'm glad he applies for MOTU and fully support him.

Specific Experiences of working together

Areas of Improvement

Add (LP: #1234567) consistently. Smile :-)


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

Andrewsomething/MOTUApplication (last edited 2009-05-14 21:10:51 by 94-169-116-60)