On 8 October 2012 18:19, Johnson, Eric <er...@mips.com> 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