projects / mirror_qemu.git / blame
| Commit | Line | Data |
|---|---|---|
| cd6b1674 KC |
1 | .. _stable-process: |
| 2 | ||
| 7aa54229 CH |
3 | QEMU and the stable process |
| 4 | =========================== | |
| 5 | ||
| 6 | QEMU stable releases | |
| 7 | -------------------- | |
| 8 | ||
| 9 | QEMU stable releases are based upon the last released QEMU version | |
| 10 | and marked by an additional version number, e.g. 2.10.1. Occasionally, | |
| 11 | a four-number version is released, if a single urgent fix needs to go | |
| 12 | on top. | |
| 13 | ||
| 14 | Usually, stable releases are only provided for the last major QEMU | |
| 15 | release. For example, when QEMU 2.11.0 is released, 2.11.x or 2.11.x.y | |
| 16 | stable releases are produced only until QEMU 2.12.0 is released, at | |
| 17 | which point the stable process moves to producing 2.12.x/2.12.x.y releases. | |
| 18 | ||
| 19 | What should go into a stable release? | |
| 20 | ------------------------------------- | |
| 21 | ||
| 22 | Generally, the following patches are considered stable material: | |
| 174b72aa CH |
23 | |
| 24 | * Patches that fix severe issues, like fixes for CVEs | |
| 25 | ||
| 26 | * Patches that fix regressions | |
| 7aa54229 CH |
27 | |
| 28 | If you think the patch would be important for users of the current release | |
| 29 | (or for a distribution picking fixes), it is usually a good candidate | |
| 30 | for stable. | |
| 31 | ||
| 32 | ||
| 33 | How to get a patch into QEMU stable | |
| 34 | ----------------------------------- | |
| 35 | ||
| 36 | There are various ways to get a patch into stable: | |
| 37 | ||
| 38 | * Preferred: Make sure that the stable maintainers are on copy when you send | |
| 39 | the patch by adding | |
| 40 | ||
| 41 | .. code:: | |
| 42 | ||
| 43 | Cc: qemu-stable@nongnu.org | |
| 44 | ||
| 45 | to the patch description. By default, this will send a copy of the patch | |
| 46 | to ``qemu-stable@nongnu.org`` if you use git send-email, which is where | |
| 47 | patches that are stable candidates are tracked by the maintainers. | |
| 48 | ||
| 49 | * You can also reply to a patch and put ``qemu-stable@nongnu.org`` on copy | |
| 50 | directly in your mail client if you think a previously submitted patch | |
| 51 | should be considered for a stable release. | |
| 52 | ||
| 53 | * If a maintainer judges the patch appropriate for stable later on (or you | |
| 54 | notify them), they will add the same line to the patch, meaning that | |
| 55 | the stable maintainers will be on copy on the maintainer's pull request. | |
| 56 | ||
| 57 | * If you judge an already merged patch suitable for stable, send a mail | |
| 58 | (preferably as a reply to the most recent patch submission) to | |
| 59 | ``qemu-stable@nongnu.org`` along with ``qemu-devel@nongnu.org`` and | |
| 60 | appropriate other people (like the patch author or the relevant maintainer) | |
| 61 | on copy. | |
| 62 | ||
| 63 | Stable release process | |
| 64 | ---------------------- | |
| 65 | ||
| 66 | When the stable maintainers prepare a new stable release, they will prepare | |
| 67 | a git branch with a release candidate and send the patches out to | |
| 68 | ``qemu-devel@nongnu.org`` for review. If any of your patches are included, | |
| 69 | please verify that they look fine, especially if the maintainer had to tweak | |
| 70 | the patch as part of back-porting things across branches. You may also | |
| 71 | nominate other patches that you think are suitable for inclusion. After | |
| 72 | review is complete (may involve more release candidates), a new stable release | |
| 73 | is made available. |