qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

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