CoreDevApplication

Differences between revisions 2 and 3
Revision 2 as of 2010-12-07 01:06:43
Size: 5257
Editor: pool-74-107-147-166
Comment:
Revision 3 as of 2010-12-07 01:10:21
Size: 5182
Editor: pool-74-107-147-166
Comment:
Deletions are marked like this. Additions are marked like this.
Line 54: Line 54:
I have to think pretty long and hard to come up that could have been handled better. The one situation I can think of, rather late in the development cycle RAOF flew to the X.org developer's conference, and while he was en route one of the bugs he had been working on became critical. Since he was unavailable I got called in to troubleshoot. It later turned out that RAOF already had a fix for it, but just hadn't gotten it uploaded. I think this could have been handled better if the status of the bug had been recorded more verbosely in the bug tracker or in git. The one situation I can think of that could have been handled better involved a bug that RAOF already had a solution for, but didn't get it uploaded before leaving on a long duration airplane flight. While he was en route, the bug became high profile, but the solution hadn't been posted to git or the bug report, so we ended up duplicating efforts unnecessarily. In the grand scheme of things it was pretty minor (the bug was solved), but better communication of status could have saved time.

I, Christopher Halse Rogers, apply for core-dev.

Name

Christopher Halse Rogers

Launchpad Page

http://launchpad.net/~raof

Wiki Page

ChrisHalseRogers

Who I am

I'm Chris Halse Rogers, and I work for Canonical on the Desktop team mainly maintaining the X stack. I'm also involved in the Debian & Ubuntu Mono teams, and upstream on GNOME Do and Docky.

My Ubuntu story

I started using Ubuntu around the Breezy release, and started contributing in areas I was interested in soon after; first multimedia, then Mono and the nouveau drivers.

My involvement

Examples of my work / Things I'm proud of

I'm pretty proud of my work on Do, particularly wandering around UDSs & sprints and watching people use it. I'm pleased with how the graphics stack in Maverick ended up.

Areas of work

I've worked on UNE and F-Spot towards the end of the Lucid release, as the primary member of the Ubuntu-X team for the Maverick release, and now continue in Ubuntu-X.

Things I could do better

I keep my work on packages in the pkg-xorg git repositories on my system for too long; I need to push the incomplete changes publicly more frequently to aid collaboration.

Plans for the future

General

  • Keep X ticking over, and improve how we deal with unusual & broken hardware.

  • Ensure X supports what the DX team needs, and fix it where we hit broken edges.
  • Keep an eye on the nascent open-source GPU video decoding stack and make sure we've got all the interesting bits in Ubuntu.

What I like least in Ubuntu

Not specific to Ubuntu, but generally - the lack or backwardness of C# bindings for our platform. Python is getting it much more right with Py-GI. I think I can write a C# gobject-introspection binding generator, and am working on one.


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.

Bryce Harrington

General feedback

I've been working with RAOF for a few years now on maintaining X packages. I really appreciate how patient he is with bug reporters, and how good he is at following up with them until their issue is solved. He also keeps a good pulse on upstream developments, which helps him spot patches worth inclusion in Ubuntu. I also respect how deeply he groks the X packaging complexities of mesa, libdrm, and other dark corners of X.org that few packagers fear to tread.

Beyond X, he's had his hands in a number of other areas of the distro, which gives me confidence that he can be trusted with core development privileges Ubuntu-wide.

Specific Experiences of working together

I worked most closely with RAOF during the Lucid development cycle, where we brought in the -nouveau driver with Kernel Mode Setting support. This required extensive coordination between us and the kernel team, as well as coordination with Debian and upstream. The packaging work was complex and error prone, with very high risks of severe breakage (e.g. boot failure and system lockups) if things were done incorrectly. The fact that we were able to transition from -nv to -nouveau, enable KMS, and not leave a smoking crater where our userbase was, is testament to RAOF's attention to quality and caution in rolling out dangerous changes.

I've reviewed and sponsored many of RAOF's uploads and find his work is trustworthy and reliable.

The one situation I can think of that could have been handled better involved a bug that RAOF already had a solution for, but didn't get it uploaded before leaving on a long duration airplane flight. While he was en route, the bug became high profile, but the solution hadn't been posted to git or the bug report, so we ended up duplicating efforts unnecessarily. In the grand scheme of things it was pretty minor (the bug was solved), but better communication of status could have saved time.

Areas of Improvement

Like I mentioned above, given the X team's distribution in time and space, more verbose communication of current status on bugs would probably help save co-workers some time and help avoid duplication of effort. But I think this is holds true of all of us X packager guys.


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


CategoryCoreDevApplication

ChrisHalseRogers/CoreDevApplication (last edited 2011-02-25 02:40:37 by cpe-75-180-27-10)