aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorCornelia Huck <cohuck@redhat.com>2018-02-09 14:03:33 +0100
committerCornelia Huck <cohuck@redhat.com>2018-02-19 10:51:16 +0100
commit7aa54229cfd24935d5d7bcc48534fe01934f3f52 (patch)
tree4dd8fdc770edf3c34b1c57a067106986860757cf /docs
parente5ecc287a7bd24a1364e23e263cb60cfc8d21eb5 (diff)
downloadqemu-7aa54229cfd24935d5d7bcc48534fe01934f3f52.zip
qemu-7aa54229cfd24935d5d7bcc48534fe01934f3f52.tar.gz
qemu-7aa54229cfd24935d5d7bcc48534fe01934f3f52.tar.bz2
docs: document our stable process
Some pointers on how to get a patch into stable. [contains some suggestions by mdroth and eblake] Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Diffstat (limited to 'docs')
-rw-r--r--docs/devel/stable-process.rst69
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.