qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: qemu-devel@nongnu.org
Cc: mdroth@linux.vnet.ibm.com, Cornelia Huck <cohuck@redhat.com>
Subject: [Qemu-devel] [PATCH RFC/D] docs: document our stable process
Date: Fri,  9 Feb 2018 14:11:12 +0100	[thread overview]
Message-ID: <20180209131112.2068-1-cohuck@redhat.com> (raw)

Some pointers on how to get a patch into stable.

Signed-off-by: Cornelia Huck <cohuck@redhat.com>
---

This probably needs more love, but I'd like to have at least _some_
kind of documentation.

Maybe this should also go into the wiki?

---
 docs/stable-process.rst | 57 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)
 create mode 100644 docs/stable-process.rst

diff --git a/docs/stable-process.rst b/docs/stable-process.rst
new file mode 100644
index 0000000000..2502823dc5
--- /dev/null
+++ b/docs/stable-process.rst
@@ -0,0 +1,57 @@
+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, a stable release is only done for the last released version.
+
+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. This will make git add the stable maintainers
+   on copy when your patch is sent out.
+
+* If a maintainer judges the patch appropriate for stable later on (or you
+  notify them), they will add the same line to your 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
+  to ``qemu-stable@nongnu.org`` 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. 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.
-- 
2.13.6

             reply	other threads:[~2018-02-09 13:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-09 13:11 Cornelia Huck [this message]
2018-02-12  3:03 ` [Qemu-devel] [PATCH RFC/D] docs: document our stable process Michael Roth
2018-02-12 12:36   ` Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180209131112.2068-1-cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).