Elliot Murphy applying for MOTU and per-package upload rights

Elliot Murphy elliot at canonical.com
Fri Jan 22 07:42:52 GMT 2010


Hi!

On Thu, Jan 21, 2010 at 4:45 AM, Emmet Hikory <persia at ubuntu.com> wrote:
> Elliot Murphy wrote:
>> Hi! I'd like to apply for MOTU and some per-package upload rights for
>> packages in main that relate closely to my daily work.
>
>    I'm a little uncomfortable recommending per-package upload rights
> for packages with no previous entries in the distribution changelog
> (either as the uploader or as a contributor) or upstream ChangeLog,
> AUTHORS, NEWS, etc.  Would you please explain your relationship with
> evolution-couchdb and couchdb-glib in more detail?

Ah yes. Rodrigo, the primary author,  works for me and I've done lots
of code review on those as he wrote them. I'd like to be able to
sponsor his work. If it helps, I could prepare the next uploads for
those packages.

>    In regards to your MOTU application, I believe you're completely
> on the right track, but generally either prefer to see a higher number
> of uploads or much more significant endorsements from others in the
> development community.  This may just be an artifact of the continuing
> changes to your application (you've received one endorsement and three
> positive comments since sending your mail), but I generally prefer to
> see either more endorsements or a larger body of reviewable code
> changes as part of the application.

https://edge.launchpad.net/~statik/+uploaded-packages shows 17
packages. I spend the majority of my time coaching other engineers on
their work. I've contacted many different people who either sponsored
uploads for me or are otherwise familiar with my development skills
and personal judgement, so I hope there will be sufficient
endorsements.

>    Some questions after reviewing your application:
>
>    You state that you have interest in gardening universe and working
> with more erlang applications.  How have your efforts been going in
> the past few weeks?  I see some work in this area, both in packaging
> and in bug management, but I'm more curious as to your experience in
> doing it, and whether you feel that you're part of a team responsible
> for these things, or just starting out.

Universe is huge, and I see a definite need for more people to be
involved. So far I've mostly fixed bugs that affected me, or worked on
packaging new software that I want to use and would be beneficial to
other Ubuntu users. I definitely feel a part of Universe, like my
efforts there can make a huge difference for whoever uses a software
package that might not be the most popular in the world, but is quite
important to the people who use it. One of my favorite things about
universe is the huge collection of software there, and it's a neat
feeling to browse through and see "what could I help make better
today".

For erlang, I've done a variety of things from consulting with the
Erlang development team at Ericsson during the main inclusion process
in Karmic striving to resolve issues around embedded zlib, and the
release of the Erlang test suite. I also set up lp:erlang, with
imports of the last 10 years of Erlang tarball releases into bzr.
Since then the Erlang team has started using github to publish daily
snapshots, which is a big step forward. Also, I set up the
lp:~erlang-dev PPA in order to make life easier for Erlang developers
on Ubuntu, it contains erlang packages rebuilt with debug symbols so
that dialyzer works on the stdlib. I've also worked on couchdb, this
package is central to my everyday work. I coached the RabbitMQ team on
working with Debian and Ubuntu more effectively at the time when they
were frustrated with trying to get RabbitMQ into Debian and Ubuntu,
and also have been doing work on python client libraries for RabbitMQ.
There is a lot of innovation happening in systems written in Erlang
right now, and I hope to do some work with ejabberd, as well as get
things like webmachine and riak into Debian and Ubuntu. I'd also like
to do some work with http://code.google.com/p/erlrc/ and get some best
practices going for deploying Erlang applications on Ubuntu in cloudy
environments. I think very few Ubuntu developers use Erlang at the
moment, and I want to make Ubuntu a more attractive platform for
Erlang developers to use (it breaks my heart to see them all using OS
X when Ubuntu has so much potential).

>    You also state that you've joined the debian-python and
> debian-erlang teams: are you encoutering many issues that would
> warrant specific divergence in Ubuntu for packages you're working on
> in these teams?  Correspondingly, what general level of interest in
> the state of the pacakges in Ubuntu do you see in those teams?

The debian-python team rocks. So far I've imported 1 new package to
svn there, plan to do all future python packaging work there instead
of Ubuntu, and bring back any remaining packages that I'd gotten into
Ubuntu directly. I did see some flaming about doko, and some debian
developers seem quite unhappy about the state of python, but I didn't
get all the background on this.

The debian-erlang team has been a challenging experience. That team
was down to a single person when I joined in order to pick up
maintenance of couchdb. Another person joined at the same time, became
co-maintainer, and there was quite a big dispute over one of the
changes to couchdb that we made in Ubuntu (the package split). This
was recently resolved, and we should soon be able to sync couchdb from
debian rather than carrying Ubuntu specific changes. I will try to do
any future packaging work for software written in Erlang here rather
than Ubuntu, but it's not as stable a situation as the python team.

I have seen first hand that it can be necessary to diverge in Ubuntu
in order to solve issues fast and have Ubuntu ship on time. I have
also seen that it's worth the effort to participate in Debian even
though it may take longer to get things done.

>    You state that you find application for MOTU very difficult, and
> suggest that we might improve the tools for code review.  Do you have
> any specific suggestions on how your code could be better reviewed?
> At least for me, the current procedure is to browse changelogs of
> previously uploaded packages  or other highlighted packages and review
> diffs available on launchpad.  I'd be very happy to hear any
> suggestions for better ways to review code contributions, and would
> directly apply them to evaluation of your work.  Additionally, you say
> that it feels awkward to ask for endorsements for your application: do
> you have any alternate suggestions about ways to maintain social
> coherence within the development community?

I think a process that requires prospective MOTUs to review proposed
uploads would be a very effective way to share knowledge and build
that coherence. Currently I've learned most of what I know about
packaging by reading, trial and error, and then getting my work
reviewed at the last possible minute, then going and doing rework. I
think if I had been reviewing other peoples work from the beginning, I
would have learned more quickly. On the development teams that I
manage, I require every branch to be reviewed by two other developers,
and brand new developers to the team begin reviewing code on their
first day. Developers also spend 1 day a week doing on-call code
review - if no branches are proposed they are free to do their own
work, but if any branches are proposed then code review is the top
priority. Nobody, not even the most senior developer on the project,
lands code without it going through review. "Never work alone" so to
speak.

Your question about social coherence I think is really about how to
efficiently evaluate a persons ability to do quality work, their
capacity for good judgement and playing well with everyone else when
disagreements arise. A reputation based system of personal
recommendations can go part of the way. It is also prone to popular or
very active people being accepted easily, with more opportunistic yet
highly skilled contributors left wondering just where the bar is. If
you can consistently get time from someone who is already an Ubuntu
developer, then you're likely to make rapid progress. If you're trying
to make it on your own without having a personal relationship with
existing Ubuntu developers, then it feels a bit more daunting. On
other projects that I've participated in such as the Drizzle database
project, you get commit rights after sending in 2 or 3 good patches.
I've worked on 17 packages and am still pushing my luck with a MOTU
application right now. Writing a database and assembling an operating
system are both serious and scary responsibilities. One of my enduring
fascinations is how to balance the checks and controls for quality
with enticing new contributors to get involved - is it better to try
and have people who never make mistakes, or is it better to embrace
mistakes and set up a review system that is likely to catch the
mistakes before they do damage? It's a tricky balance. I care about
Ubuntu enough that I want more people to get involved in Ubuntu
development, and the best way i know to make that happen is to become
an Ubuntu developer myself, and then show others the way. I think that
I've demonstrated good judgement over the course of my professional
career as a software developer (working on backup and database systems
the whole time) based on the professional responsibilities that I've
been given and the way I've carried them out, but it's not so easy to
show communicate/demonstrate that judgement in a small series of
debdiffs when I only manage to squeeze in an hour or two a week to
work on Ubuntu packaging tasks. So the thing I find hard is to go on
and on trying to convince people in a public forum that I'm smart,
know the rules, and have good judgement. It just feels like boasting,
which embarrasses me, and it feels strange to try and nag the same
people over and over again to sponsor uploads just so that they will
get to know me. Perhaps I'm just too sensitive on this point. I'm
certainly not shy about demanding attention from people when I'm
working on a serious bug, so maybe I shouldn't be so shy about it when
I'm working on normal run of the mill stuff.

>
>> Unufortunately I won't be able to attend the January 8, January 29, or
>> February 12 IRC meetings, so I'd like my application to be processed by
>> email if possible
>
>    Be warned that this may not be possible.  We haven't been quick
> with email processing recently, and will shortly run out of quorum.
> If the application is not completed by 31st January, I strongly
> encourage you to apply to the Developer Membership Board directly for
> consideration of your request for PerPackageUploader permission.  I do
> not currently know how MOTU applications shall be processed after that
> date: you may do best to review the minutes of the 2nd February DMB
> meeting for guidance.

Ah, thanks for letting me know (and for the chat on IRC where you
explained this a bit more). I've rearranged my schedule so that I can
attend the Jan 28th meeting on IRC, and updated the wiki page
accordingly. I'm looking forward to it :)

-- 
Elliot Murphy | https://launchpad.net/~statik/



More information about the Motu-council mailing list