mirror of https://gitee.com/openkylin/qemu.git
70 lines
2.7 KiB
ReStructuredText
70 lines
2.7 KiB
ReStructuredText
|
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.
|