docs/devel/submitting-a-patch.rst

21    * - Patches contain Signed-off-by: Your Name <author@email>
24      - The project uses an email list based workflow. See :ref:`submitting_your_patches`
32 volume of email, often over one thousand messages in a week. The list is
33 moderated; first-time posts from an email address (whether or not you
154 (which becomes the email subject line) is "subsystem: single line
166 for fixing this bug" (they can go below the ``---`` line in the email so
225 The QEMU project uses a public email based workflow for reviewing and
232 to another list.) ``git send-email`` (`step-by-step setup guide
233 <https://git-send-email.io/>`__ and `hints and tips
234 <https://elixir.bootlin.com/linux/latest/source/Documentation/process/email-clients.rst>`__)
243 If you already configured git send-email, you can simply use `git-publish
278    ``git-send-email`` UI at https://git.sr.ht/~USERNAME/qemu/send-email
318 using ``git send-email`` to mail the files to the mailing list. (We
319 recommend `git send-email <http://git-scm.com/docs/git-send-email>`__
321 messing up whitespace. Some distributions do not include send-email in a
323 such as 'git-email' on Fedora-based systems.) Patch series need a cover
359 convenient 0/N email for others to reply to the series as a whole. A
494 fresh email or series of emails -- don't try to make it a followup to
495 version 1. (This helps automatic patch email handling tools distinguish
511 send-email <http://git-scm.com/docs/git-send-email>`__ both understand
523 previous versions, but not in the commit message itself. In an email
531 patch email, and this is where the "changes since previous version"
566 week or two, by sending an email as a reply-to-all to the patch mail,