cd6b1674d6
I completely botched up the merged[0] rST conversion of this document by
accidentally dropping entire hunks (!) of text. :-( I made it very hard
for reviewers to spot it, as the omitted text was buried deep in the
document. To fix my hatchet job, I reconverted the "SubmitAPatch"
wiki[1] page from scratch and replaced the existing rST with it, while
making sure I incorporated previous feedback.
In summary, in this reconverted edition:
- I did a careful (to the extent my eyes allowed) para-by-para
comparison of the wiki and the rST to make sure I didn't omit
anything accidentally.
- I made sure to work in the cosmetic feedback[2] that Thomas Huth
pointed out in the merged (and botched) edition:
- fix the hyperlinks in "Split up long patches"
- replace ".". with "does not end with a dot" (in "Write a meaningful
commit message" section)
- replace "---" with ``---`` so that it doesn't render as an em-dash
(there were two other occurrences; I fixed those too)
- Use "QEMU" spelling consistently in prose usage
- Add a consistent "refer to git-config" link where appropriate
Thanks to Thomas Huth and Alex Bennée for noticing it on IRC. And sorry
for my sloppiness.
Fixes: 9f73de8df033 ("docs: rSTify the "SubmitAPatch" wiki")
[0] https://gitlab.com/qemu-project/qemu/-/commit/9f73de8df033
[1] https://wiki.qemu.org/index.php?title=Contribute/SubmitAPatch&oldid=10387
[2] https://lists.nongnu.org/archive/html/qemu-devel/2021-11/msg03600.html
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
Message-Id: <20211119193118.949698-2-kchamart@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[thuth: Some more cosmetical changes, fixed links from external to internal]
Signed-off-by: Thomas Huth <thuth@redhat.com>
74 lines
2.7 KiB
ReStructuredText
74 lines
2.7 KiB
ReStructuredText
.. _stable-process:
|
|
|
|
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.
|