- 1 Does QEMU have internal documentation?
- 2 I sent a patch but no one responded, what do I do?
- 3 I followed SubmitAPatch but I still haven't seen a response, what do I do?
- 4 I received feedback, do I need to resubmit?
- 5 I received conflicting feedback, what do I do?
- 6 Can I submit patches through Launchpad, github, or other tools?
- 7 Can I send patches against a previous release or distribution package?
- 8 How do I get a patch into a stable release?
- 9 I need help with a school/university project involving QEMU...
- 10 How can I encourage people to review my patches more quickly?
- 11 I can't write code. Can I still contribute?
Does QEMU have internal documentation?
Not really. The best source of internal documentation are the various KVM Forum talks and potentially talks at other conferences. These can be a bit out dated but often are good overviews of various subsystems.
I sent a patch but no one responded, what do I do?
First, make sure that you followed SubmitAPatch especially ensuring that you've CC'd the appropriate maintainer. qemu-devel has a very high volume of traffic so it's easy for patches to get lost if the right people aren't CC'd.
I followed SubmitAPatch but I still haven't seen a response, what do I do?
Are you submitting a patch during the SoftFreeze or HardFreeze? If so, the maintainers may be busy preparing the next release. You may need to wait until the next development window opens up and resubmit your patch.
Even during the development windows, most QEMU maintainers are very busy. It's normal for a patch to not get a response for a week or possibly two. If your patch hasn't gotten a response after two weeks, you can reply to the patch with a simple "ping" message. This will raise the thread to the top of most people's inboxes and give your patch another chance to be reviewed.
You can repeat this process two or three times. It's extremely unusual for a patch to not get feedback after being pinged a few times.
I received feedback, do I need to resubmit?
In order for your patch to be merged, it must either (1) receive a Reviewed-by by a trusted reviewer on qemu-devel or (2) be reviewed by a maintainer and accepted into their tree.
If you received feedback, you should correct the issues pointed out and resubmit the patch indicating that this is a new version of the patch (by saying v2 in the subject).
I received conflicting feedback, what do I do?
QEMU is a community of developers that sometimes have conflicting opinions. Figuring out the right way to resolve conflicting feedback is a skill developed overtime and requires understanding who's feedback is the most relevant for a given subsystem.
MAINTAINERS is usually a good indicator of who's feedback is most important for the various parts of QEMU but that's not guaranteed.
Can I submit patches through Launchpad, github, or other tools?
Can I send patches against a previous release or distribution package?
No. All patches should be sent against the latest qemu.git tree.
How do I get a patch into a stable release?
When submitting the patch, it's sufficient to CC qemu-stable to queue the patch for consideration in a stable release. Ultimately, the stable maintainer will decide which patches to backport to stable releases.
A patch must be included in the latest qemu.git tree before it can be backported to stable.
I need help with a school/university project involving QEMU...
Unless you plan to contribute changes to QEMU, it's unlikely that you'll receive much assistance from QEMU developers directly. If you do plan to contribute a feature to QEMU, you should make that clear up front.
How can I encourage people to review my patches more quickly?
The best way to encourage people to review your patches is by reviewing other people's patches. Reviewing other people's patches helps in two ways. It eliminates work a maintainer would need to do giving them more time to review your patch. It also builds good will within the community. People tend to want to help people who have demonstrated a willingness to help other people in the community.