diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/devel/stable-process.rst | 69 |
1 files changed, 69 insertions, 0 deletions
diff --git a/docs/devel/stable-process.rst b/docs/devel/stable-process.rst new file mode 100644 index 0000000..98736a9 --- /dev/null +++ b/docs/devel/stable-process.rst @@ -0,0 +1,69 @@ +QEMU and the stable process +=========================== + +QEMU stable releases +-------------------- + +QEMU stable releases are based upon the last released QEMU version +and marked by an additional version number, e.g. 2.10.1. Occasionally, +a four-number version is released, if a single urgent fix needs to go +on top. + +Usually, stable releases are only provided for the last major QEMU +release. For example, when QEMU 2.11.0 is released, 2.11.x or 2.11.x.y +stable releases are produced only until QEMU 2.12.0 is released, at +which point the stable process moves to producing 2.12.x/2.12.x.y releases. + +What should go into a stable release? +------------------------------------- + +Generally, the following patches are considered stable material: +- Patches that fix severe issues, like fixes for CVEs +- Patches that fix regressions + +If you think the patch would be important for users of the current release +(or for a distribution picking fixes), it is usually a good candidate +for stable. + + +How to get a patch into QEMU stable +----------------------------------- + +There are various ways to get a patch into stable: + +* Preferred: Make sure that the stable maintainers are on copy when you send + the patch by adding + + .. code:: + + Cc: qemu-stable@nongnu.org + + to the patch description. By default, this will send a copy of the patch + to ``qemu-stable@nongnu.org`` if you use git send-email, which is where + patches that are stable candidates are tracked by the maintainers. + +* You can also reply to a patch and put ``qemu-stable@nongnu.org`` on copy + directly in your mail client if you think a previously submitted patch + should be considered for a stable release. + +* If a maintainer judges the patch appropriate for stable later on (or you + notify them), they will add the same line to the patch, meaning that + the stable maintainers will be on copy on the maintainer's pull request. + +* If you judge an already merged patch suitable for stable, send a mail + (preferably as a reply to the most recent patch submission) to + ``qemu-stable@nongnu.org`` along with ``qemu-devel@nongnu.org`` and + appropriate other people (like the patch author or the relevant maintainer) + on copy. + +Stable release process +---------------------- + +When the stable maintainers prepare a new stable release, they will prepare +a git branch with a release candidate and send the patches out to +``qemu-devel@nongnu.org`` for review. If any of your patches are included, +please verify that they look fine, especially if the maintainer had to tweak +the patch as part of back-porting things across branches. You may also +nominate other patches that you think are suitable for inclusion. After +review is complete (may involve more release candidates), a new stable release +is made available. |