Ubuntu Contributing Developer Application : Marc Cluet

Emmet Hikory persia at ubuntu.com
Sun Jul 3 11:09:07 UTC 2011


Mackenzie Morgan wrote:
> Marc Cluet wrote:
>> You can find the application in the
>> wiki https://wiki.ubuntu.com/MarcCluet/UbuntuContributingDeveloper
>
> The result of this application was a split vote.
> +1:  maco, bdrung, stgraber
> +0: geser (later noted that with LP account merger, more sponsored
> uploads showed up, but still on the fence, like +0.5, if possible)
> -1: cody-somerville
>
> For a total of +2.  Debate followed about whether majority-of-board or
> majority-of-quorum-present was needed. Temporary resolution was to ask
> here for Laney & persia to give their votes.

    +0 from me.  Due to controversy surrounding this application, I
feel the need to explain my vote in depth:

    In the case of applications for contributing developer, I only
consider "significant" and "sustained", without expecting highly
complex solutions during code review, although I limit my
investigation in these cases to work done *as a developer*, rather
than work in the wider community.  In rare cases, large volumes of
work external to pure development may sway me, but I'd much rather see
people who achieved that be granted membership explicitly for that
work, rather than for their development work, if the development work
is comparatively poor.

    During code review, I find a library link change, which may have
been more interestingly addressed by automatic generation in
debian/rules, a new upstream with no identified integration
modifications, a cleanup of a configuration mechanism (with a missing
',' in debian/control), a new upstream with significant integration
work (but also including a lintian bump, which we tend to try to
avoid), another new upstream with significant integration (but using
metapackages and virtual packages, rather than expansion variables in
debian/control and aggressive use of debconf-set-selections, rather
than providing defaults in debconf templates), and a nicely executed
debconf-driven configuration patch.  Were I considering an application
for upload rights, I'd be fairly unhappy with some of the issues
highlighted above, although in the case of a contributing developer, I
am often willing to ignore some of these if there are other
considerations (high volume of work, clear evidence of having taken
full responsibility for maintenance of specific packages, etc.).  I'd
really like to see one of a) some larger or more interesting changes,
b) richer history of repeated uploads to similar packages, especially
short-term re-uploads to fix issues like those described above, or c)
demonstration of understanding of one or more issues and wide
application to many packages in the archive.  While the current work
is as expected for new developers joining Ubuntu, it does not yet meet
my definition of "significant", in part because of the volume, and in
part because of the number of cases where another developer will need
to re-upload the package to address issues, such that it is not yet an
obvious net benefit to the project as a whole.

    In this case, the period of consistent credited uploads starts
from the end of May, 2011 (and could be argued to have started from
last week, depending on the interpretation of the data).  While I am
often willing to be less strict about the sustained test when
applicants are employed in a position that considers improvement of
software in the Ubuntu archive a primary job responsibility (simply
because I trust that their employer will help ensure continued
contributions), I am not convinced that one can successfully absorb
sufficient cultural bias from the Ubuntu development community in such
a short period.  I'd really like to see some more time spent working
with other developers and other members of the wider Ubuntu community
to help build a richer understanding of our cultural values.  On the
other hand, all available evidence indicates that this absorbsion is
underway, and should be complete in relatively short order.  There's
also some admin work needing doing, like ensuring one has a wiki page,
etc. :)

    I choose to vote +0 because while I have not been convinced that
Marc currently meets my personal expectations for Ubuntu Members, I
also have found no information that any of Marc's activity has not
been part of the path towards Ubuntu Membership, and have no objection
to his elevation if others feel he has met their personal criteria.  I
fully expect that another month or two of work will enable Marc to
meet my requirements.

-- 
Emmet HIKORY




More information about the Devel-permissions mailing list