Re: [Qemu-devel] [PATCH v2] docs: document our stable process

[Michael Roth]

Quoting Cornelia Huck (2018-02-12 06:40:08)
> Some pointers on how to get a patch into stable.
> 
> [contains some suggestions by mdroth]
> Signed-off-by: Cornelia Huck <address@hidden>
> ---
> RFC/D->v2: added mdroth's suggestions
> ---
>  docs/stable-process.rst | 67 
> +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 67 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..c571204c9f
> --- /dev/null
> +++ b/docs/stable-process.rst
> @@ -0,0 +1,67 @@
> +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 the stable process moves to producing 2.12.x/2.12.x.y releases.

"at which point"

Sorry, looks like one of my errors slipped through :)

With that and Eric's suggestions addressed:

Reviewed-by: Michael Roth <address@hidden>

> +
> +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: address@hidden
> +
> +  to the patch description. By default, this will send a copy of the  patch
> +  to address@hidden 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 address@hidden 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
> +  address@hidden along with address@hidden 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
> address@hidden 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
>