jcs.org
qemu with hax to log dma reads & writes
jcs.org/2018/11/12/vfio
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>
+69
+69
docs/devel/stable-process.rst
+69
docs/devel/stable-process.rst
···
1
+
QEMU and the stable process
2
+
===========================
3
+
4
+
QEMU stable releases
5
+
--------------------
6
+
7
+
QEMU stable releases are based upon the last released QEMU version
8
+
and marked by an additional version number, e.g. 2.10.1. Occasionally,
9
+
a four-number version is released, if a single urgent fix needs to go
10
+
on top.
11
+
12
+
Usually, stable releases are only provided for the last major QEMU
13
+
release. For example, when QEMU 2.11.0 is released, 2.11.x or 2.11.x.y
14
+
stable releases are produced only until QEMU 2.12.0 is released, at
15
+
which point the stable process moves to producing 2.12.x/2.12.x.y releases.
16
+
17
+
What should go into a stable release?
18
+
-------------------------------------
19
+
20
+
Generally, the following patches are considered stable material:
21
+
- Patches that fix severe issues, like fixes for CVEs
22
+
- Patches that fix regressions
23
+
24
+
If you think the patch would be important for users of the current release
25
+
(or for a distribution picking fixes), it is usually a good candidate
26
+
for stable.
27
+
28
+
29
+
How to get a patch into QEMU stable
30
+
-----------------------------------
31
+
32
+
There are various ways to get a patch into stable:
33
+
34
+
* Preferred: Make sure that the stable maintainers are on copy when you send
35
+
the patch by adding
36
+
37
+
.. code::
38
+
39
+
Cc: qemu-stable@nongnu.org
40
+
41
+
to the patch description. By default, this will send a copy of the patch
42
+
to ``qemu-stable@nongnu.org`` if you use git send-email, which is where
43
+
patches that are stable candidates are tracked by the maintainers.
44
+
45
+
* You can also reply to a patch and put ``qemu-stable@nongnu.org`` on copy
46
+
directly in your mail client if you think a previously submitted patch
47
+
should be considered for a stable release.
48
+
49
+
* If a maintainer judges the patch appropriate for stable later on (or you
50
+
notify them), they will add the same line to the patch, meaning that
51
+
the stable maintainers will be on copy on the maintainer's pull request.
52
+
53
+
* If you judge an already merged patch suitable for stable, send a mail
54
+
(preferably as a reply to the most recent patch submission) to
55
+
``qemu-stable@nongnu.org`` along with ``qemu-devel@nongnu.org`` and
56
+
appropriate other people (like the patch author or the relevant maintainer)
57
+
on copy.
58
+
59
+
Stable release process
60
+
----------------------
61
+
62
+
When the stable maintainers prepare a new stable release, they will prepare
63
+
a git branch with a release candidate and send the patches out to
64
+
``qemu-devel@nongnu.org`` for review. If any of your patches are included,
65
+
please verify that they look fine, especially if the maintainer had to tweak
66
+
the patch as part of back-porting things across branches. You may also
67
+
nominate other patches that you think are suitable for inclusion. After
68
+
review is complete (may involve more release candidates), a new stable release
69
+
is made available.