Fixing QEMU bugs

From PRPL
Jump to: navigation, search

Fixing bugs in QEMU is straightforward and follows a pretty standard Github reporting model. The process should go as follows:

Is the bug reported yet?[edit]

Make sure the bug has been reported on the issues tracker. If it hasn't been reported, make sure you report it before you continue. Make sure to follow the issue reporting guidelines.

Fork from the QEMU Repository[edit]

Fork the QEMU repository through the Github website

Fix the bug[edit]

Edit the code as necessary to fix the bug. Make sure to follow the coding conventions for QEMU

Tell us what you did[edit]

When you commit, make sure to write a quick description of the work you did. As part of that, make sure you follow the next two guidelines:

Tell us the issue it closes[edit]

Github issues supports issues being closed automatically as part of a commit. To support that just add the phrase Closes #n where n is the number of the Github issue you're fixing. For example, if you're fixing issue number 3, add Closes #3 to your commit message.

Sign your work[edit]

To help us keep track of who is contributing patches to QEMU, we use a "sign-off" procedure on code changes. The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open-source patch. The rules are pretty simple: if you can certify the below:

By making a contribution to this project, I certify that:
  
(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or
  
(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or
  
(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.
  
(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

Then you just add a line to your commit message saying:

Signed-off-by: Random J Developer <random@developer.example.org>

using your real name.

If, for personal safety reasons, you cannot use your real name, please contact prpl Community Manager Eric Schultz before submitting your pull request; an alternate procedure will be used.

Submit a pull request[edit]

Send a pull request to the QEMU Github page. Make sure to provide a detailed description of your work; we love what you've done and the committers want to understand it.

Answer any questions on the pull request and make changes as necessary[edit]

It's very common for other PEG participants to have questions or concerns about your changes. This is totally normal; very few changes to a project are perfect the first time. Answer the questions as best you can and it's okay to ask other folks questions too.

If you're asked to make changes, follow the same process as before. Make sure to follow the "sign-off" procedure for additional commits add to your pull-request.

The community decides on whether to accept your pull request[edit]

For your patch to be merged, there will need to be at least three +1 votes and no -1 votes (or any -1 votes have been rescinded). The pull request needs to have been open for at least 72 hours. If all those conditions are true, a committer will merge the pull request. If it hasn't been merged, ask a committer to merge it on your behalf.

An exception to this process occurs for feature branches where the pull request is coming from a committer. In that case, the committer may merge the pull request immediately. The merge may be reverted later after a review as part of the Merge-then-review system

Celebrate![edit]

You're now an official code contributor to the QEMU PEG. We're excited to have you involved!