On 05.04.2011, at 08:01, Brad Hards wrote: > On Tue, 5 Apr 2011 05:59:27 am Anthony Liguori wrote: >> - Trivial patch monkeys^Wteam -- this is an idea Stefan and I have been >> kicking around to help some of the trivial patches get more attention on >> the mailing list > I saw a wiki page (http://wiki.qemu.org/Contribute/TrivialPatches) that I > assumed was historical - bad assumption given the page history of course.
Hrm. I don't even know that page. Where is it linked? Maybe it should be linked on the http://wiki.qemu.org/Contribute/StartHere page? > As an outsider / new contributor, it isn't easy to see how to get patches > noticed, and how different things should feed into the tree(s). For instance, > is my patch being ignored because I forgot the Signed-off-by line, or is the > maintainer away for a month? Or am I just not "in the club"? That's sometimes even hard for people who have been working on Qemu for ages :). I'm not sure how to improve the situation. I as a maintainer usually ask other people to take over for me when I'm off on vacation, so contributers don't get exactly that feeling. But some parts of Qemu are just plain unmaintained, so nobody feels responsible. > It isn't even easy to figure out what trees there are (apart from the main > one) > and a google search for "qemu git" produces some misleading links to savannah > and places other than git://git.qemu.org/qemu.git. It would also be useful if > http://git.qemu.org/git/qemu.git/ and http://git.qemu.org/qemu.git worked > again. Perhaps a list of main trees on the wiki or in MAINTAINERS might help? > Even a list of obsolete trees might be useful. Yes, please add that to the wiki :). I'd also like to see the savannah one just deactivated. Last time I checked it wasn't synced, so you simply get an old snapshot which is the worst case scenario for everyone. > It would probably also help if there was a little more documentation on the > process bits (e.g. whether I need a public git tree, or mailing patches is > always preferred, and maybe some links to better-practice git setups to > ensure You don't need a public git tree. But try to imagine you're a maintainer. Usually, those people just tend to have full-time jobs and look at patches along the way. If you send in a patch set of 20 patches, it's a lot easier for them to clone your tree to at least try out the patches than to apply them manually. So rule of thumb is: As of 5 patches, creating a git tree helps getting your patches tested/reviewed. I usually just push my work to repo.or.cz. They offer their services for free and are available almost every time I've needed them :). > patches make it through OK) and about what is expected in terms of code What exactly do you mean by better-practice git setups? > quality and resubmission. It would also help to have some explanatory text > for > some of the architectural docs that are available (e.g. there is a lot of > words on the wiki about QED, and I guess its some kind of storage / disk > thing, but I have no idea why its important, or even if I should know about > it). Take a look at http://wiki.qemu.org/Contribute/StartHere. It links to (rudimentary) explanations for QED. We don't have a full-on architectural doc though. And I'm not sure we ever will - unless people volunteer to write documentation instead of code :). > I've tried to expand > http://wiki.qemu.org/Documentation/GettingStartedDevelopers to cover my > personal "a-ha" moments, but if I knew enough to write it all, then I'd > probably be more interested in getting code written too... Ah, very nice! Thank you! > I'm sorry I have more complaints than useful suggestions here. I can only say > I'll hang around (mail / IRC) as long as I feel somewhat welcome and write up > any insights you can offer. You certainly welcome :). And thanks a lot for helping out on the wiki! Alex
