Hi list, During the GSoC mentor summit I held a small summit to find out what users of QEMU think could be improved and how they perceive QEMU.
The main point brought up was that people felt ignored when sending patches. From my experience, this usually happens when patches hit a maintainer free zone. One idea to address this issue was to just apply patches half-blindly when in such a maintainer-free zone. As long as the patch doesn't seem to have side effects, the worst it would do is fix an issue for someone contributing code and break someone not contributing. After a while, a new maintainer might rise this way. We should also show people unmaintained areas. The conclusion was a wiki page with subsystems and status so people know what to expect. Maybe we could generate this from the MAINTAINERS file? Also, an easy way of counterfighting the feeling ignored part is to tell people that they just hit an unmaintained area. There's nothing more frustrating than sending a patch and get no reply. Receiving a reply "Sorry, this area is unmaintained. Please find someone to review it." would already be enough for most people. For 68k, Chris Johns from RTEMS stepped up and said he would happily maintainer that target. He will try to work on QEMU a bit more to gain trust and review patches. The RTEMS guys use QEMU to do coverage testing of their kernel code. They run their test-cases and see if all of their code and branches have been hit. Adacore seems to have a patches version of QEMU to provide an easily parsable log file for that sort of thing. Might be a good idea to consolidate upstream. Patches welcome :) A lot of people seem to also have code that doesn't make sense upstream, for example implementing a one-off device that only really matters for their own devboard which nobody else owns. For such cases, having a plugin framework would be handy. I interestingly enough got into the same discussion on LinuxCon with some QEMU downstreams. Alex
