MOTU application for Michael Casadevall (NCommander/sonicmctails)

[Michael Casadevall]

I'll answer all questions in one specific email

> What impression did you get from the Mentoring Programme generally? Is
> there anything that could be improved?

It should be noted I was in the advanced mentoring programming, so I'm
not sure how relevant my experience is overall, but I found mentoring
to be extremely useful. I learned a great deal about packaging
updates, some of the more specifics of updating packages, so names
bumps and transitions more in detail, as well as helping to package
entire GNOME releases, and working out a workflow to allow me to
update packages, for instance, checking configure.in (or equivelent)
to make sure all build-deps are up to date with their minimal
requirements for instance, a handy tip I might not have otherwise
picked up. The mentoring program for me was extremely beneficial, and
I would recommend it to next person aspiring to becoming an MOTU. I've
even started offering mentorship on some of my bugs in Xubuntu to help
get people who have shown interest in development to help them get
fixes in place. Again, thanks you Sebastien Bacher.

>> After one particular string of silly mistakes, I sat down with Michael
>> and discussed this issue with him. Michael promised me that he would
>> always test his changes from that point forward. Since then, I feel
>> Michael has a better understanding and appreciation for the entire
>> process that all developers should move through when making changes.
>
> Hi Michael,
>
> Do you think there is anything concrete you can change about the way
> you work to avoid silly mistakes? We all make mistakes, I've made
> several since becoming a MOTU. Do you feel you know when to ask for
> advice if you are a little out of your depth? Do you try and adapt
> your workflows to eliminate classes of mistake?

Generally speaking, I do test instability and upgrade of packages, and
I do test bugs following reproducibly instructions especially when
dealing with things such as soname bumps and backports. Mistakes do
happen, and I'll admit I have my share on them, but I like my think my
mistake/overall upload ratio is relatively low. I do ask for help when
I feel I need it, as Emmet can attest to when giving me a crash course
in writing documentation, or Cody when I asked him to sanity check my
changes to xubuntu-docs's source package, as well as sanity checks on
my changes to the linux-lpia and linux-lpia-meta packages. It should
also be made clear that if I do make a mistake and it is later caught,
I always correct it; I don't leave my mistakes for others to go and
fix later.

As for my individual workflows, I generally use one based off my
workflow that I developed for backports, which is chiefly confirm the
original bug if possible, get a package building, get it building in
pbuilder, installing the debs from pbuilder, check upgrability, check
usability, attempt to reproduce the original bug after my patch,
prepare a debdiff or upload as the case maybe. I cite orage as one of
the more recent packages where I have applied my workflow
successfully, as well as every single backport I've tested.

On Wed, Oct 22, 2008 at 6:26 AM, James Westby <jw+debian at jameswestby.net> wrote:
> Hi Michael,
>
> Thanks for your application.
>
> On Tue, 2008-10-21 at 16:47 -0400, Michael Casadevall wrote:
>> I look forward to working in jaunty in helping get patches back in
>> Debian from Ubuntu, and attending at UDS for Jaunty to help map out
>> our future of Ubuntu. I personally would like to see better support
>> for ports, especially for studio. There are a great many PowerMac G4
>> and G5s that are used for studio work that Apple has decided to
>> support, and I would like to help bring studio to these platforms (the
>> main problem with studio is a lack of a real-time kernel for PowerPC,
>> the patches exist, they simply need to migrate into the linux-ports
>> kernel).
>>
>> I also would like to greatly work towards removing cruft from the
>> archive, such as gtk1.2, and improving both Xfce and KDE. One of my
>> largest projects in terms of general usability with Xubuntu and Xfce
>> specifically is making Xfce fully syncable from Debian with the
>> expection of the few Ubuntu specific patches, as well as helping any
>> bug
>
> You work on an impressive number of projects, and a breadth of interest
> is admirable, and something some applicants are criticised for not
> having.
>
> However, I seem to see this list continually growing, is that going
> to continue? Are you able to continue dedicating the time to existing
> projects while taking on more?
>

I won't say that this list is continually growing, its just I happen
to expand my fields knowledge more and more. Let me put to you in
another way, I am mostly active in ports and xubuntu development, this
are my priorities ATM within the community, providing PowerPC and
other ports users with a solid and stable Ubuntu distribution, and
improving the Xubuntu distribution. That being said, I don't feel
specialization in one any section of Ubuntu is good for the project;
what good is someone who can solve FTBFSs if they remain only in the
Xubuntu section of the repo. In the time I've been here, I've been
involved in Xubuntu, Kubuntu, Studio, Server, Ports, LPIA kernel
hacking, the Mozilla team, and probably other parts of the project
that I can't think off hand.

> Once you become a MOTU I expect you will come to be relied upon in
> certain positions. Will you know when you have to stop taking on
> new projects in order to dedicate the time to fulfil the
> responsibilities you have to older projects?
> Thanks,
>
> James
>
>


>

I think in some ways this has already happened, w.r.t to FTBFSes and
libtool issues. I've already been asked to look at several packages
when the explode in a shower of sparks, and I've earned a reputation
as the goto guy for difficult build failures. I've been involved in
Xubuntu development fairly early in my contributing career, and I have
remained involved through out. As stated above, I generally don't see
it as taking New Projects, but more expanding my field of knowledge,
and providing assistance where needed. I generally go where I'm most
needed, so if a new project greatly needs my abilities, it would get
my focus, but I would not simply abandon my old projects on a whim.

I think the chief example of this is REVU; I noticed several
deficiencies in REVU when I first came to the project, and worked
through most of my first month rewriting and redoing larges chunks of
the infrastructure of it now. As REVU's need for improvement dropped,
and other projects were more in need of my skill, my priorities
focused, but I never have stopped being a REVU hacker.