qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] MIPS DSP for Qemu


From: Peter Maydell
Subject: Re: [Qemu-devel] MIPS DSP for Qemu
Date: Mon, 8 Oct 2012 20:52:25 +0100

On 8 October 2012 18:19, Johnson, Eric <address@hidden> wrote:
> Peter Maydell wrote:
>> I also note that target-mips/ is currently in the "Odd Fixes"
>> maintenance state -- is anybody at MIPS in a position to step
>> up and help with bug fixing and patch review of that area?
>
> MIPS has been considering several options to address the issue of
> a MIPS target maintainer for QEMU.
>
> Since the topic has come up, what is the process for vetting a
> maintainer?

Well, I can tell you the process I went through in becoming a
co-maintainer for the ARM target (about a year or so ago now).
Basically I started out by doing a bunch of work that seemed
to need doing and that nobody else was doing at the time:
 * submitting patches to fix various bugs
 * reviewing patches other people sent to the list
 * generally taking part in discussions on list and irc
 * collecting up patches and making sure they didn't get
   forgotten
 * progressing to putting together a tree and starting to
   send pull-request emails
and about the last thing was getting the MAINTAINERS file
changed to add my name.
If there was a formal vetting process I didn't notice it :-)

My take on it is that you can begin to get done the things
you want done as "just another contributor". While you're
doing that you gradually build up trust and credibility with
the community that (a) you're going to hang around for a while
and not just pop in every three months with a new pile of patches
(b) your code is generally technically good and (c) that you
would do a good job with the other aspects of being a subsystem
maintainer (eg won't just throw any old rubbish into the tree,
ignore review comments, or only look at your own patches and
not other peoples'). Then it kind of gradually fades from
'we're going to review everything first and apply it by hand'
to pull requests being applied fairly automatically.

The distributed nature of git means there isn't a sharp dividing
line between 'maintainer' and 'somebody who does most of the work
in this area of the code'. I found getting the 'maintainer'
title didn't really mean a change in what I could get
changed/fixed in the code; it just makes some things a little
smoother and quicker administratively.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]