[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] GSoC mentor summit QEMU users session
From: |
Alexander Graf |
Subject: |
[Qemu-devel] GSoC mentor summit QEMU users session |
Date: |
Sat, 29 Oct 2011 15:52:17 +0200 |
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
- [Qemu-devel] GSoC mentor summit QEMU users session,
Alexander Graf <=