381d2c36e1
Unfortunately, the definition of the footnote syntax requires the author to use the awkward escaped space "\ " in the really common case of "footnote marker at end of word or sentence"; and in fact the rST documentation's examples of footnote syntax contain only artificial examples that do *not* use the syntax. This resulted in ugly rendering of footnotes throughout QEMU's documentation. Ensure the space is escaped whenever the footnote must attach to the preceding word, and also use a named reference for clarity. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
108 lines
3.9 KiB
ReStructuredText
108 lines
3.9 KiB
ReStructuredText
.. _maintainers:
|
|
|
|
The Role of Maintainers
|
|
=======================
|
|
|
|
Maintainers are a critical part of the project's contributor ecosystem.
|
|
They come from a wide range of backgrounds from unpaid hobbyists
|
|
working in their spare time to employees who work on the project as
|
|
part of their job. Maintainer activities include:
|
|
|
|
- reviewing patches and suggesting changes
|
|
- collecting patches and preparing pull requests
|
|
- tending to the long term health of their area
|
|
- participating in other project activities
|
|
|
|
They are also human and subject to the same pressures as everyone else
|
|
including overload and burnout. Like everyone else they are subject
|
|
to project's :ref:`code_of_conduct` and should also be exemplars of
|
|
excellent community collaborators.
|
|
|
|
The MAINTAINERS file
|
|
--------------------
|
|
|
|
The `MAINTAINERS
|
|
<https://gitlab.com/qemu-project/qemu/-/blob/master/MAINTAINERS>`__
|
|
file contains the canonical list of who is a maintainer. The file
|
|
is machine readable so an appropriately configured git (see
|
|
:ref:`cc_the_relevant_maintainer`) can automatically Cc them on
|
|
patches that touch their area of code.
|
|
|
|
The file also describes the status of the area of code to give an idea
|
|
of how actively that section is maintained.
|
|
|
|
.. list-table:: Meaning of support status in MAINTAINERS
|
|
:widths: 25 75
|
|
:header-rows: 1
|
|
|
|
* - Status
|
|
- Meaning
|
|
* - Supported
|
|
- Someone is actually paid to look after this.
|
|
* - Maintained
|
|
- Someone actually looks after it.
|
|
* - Odd Fixes
|
|
- It has a maintainer but they don't have time to do
|
|
much other than throw the odd patch in.
|
|
* - Orphan
|
|
- No current maintainer.
|
|
* - Obsolete
|
|
- Old obsolete code, should use something else.
|
|
|
|
Please bear in mind that even if someone is paid to support something
|
|
it does not mean they are paid to support you. This is open source and
|
|
the code comes with no warranty and the project makes no guarantees
|
|
about dealing with bugs or features requests.
|
|
|
|
|
|
|
|
Becoming a reviewer
|
|
-------------------
|
|
|
|
Most maintainers start by becoming subsystem reviewers. While anyone
|
|
is welcome to review code on the mailing list getting added to the
|
|
MAINTAINERS file with a line like::
|
|
|
|
R: Random Hacker <rhacker@example.com>
|
|
|
|
marks you as a 'designated reviewer' - expected to provide regular
|
|
spontaneous feedback. This will ensure that patches touching a given
|
|
subsystem will automatically be CC'd to you.
|
|
|
|
Becoming a maintainer
|
|
---------------------
|
|
|
|
Maintainers are volunteers who put themselves forward or have been
|
|
asked by others to keep an eye on an area of code. They have generally
|
|
demonstrated to the community, usually via contributions and code
|
|
reviews, that they have a good understanding of the subsystem. They
|
|
are also trusted to make a positive contribution to the project and
|
|
work well with the other contributors.
|
|
|
|
The process is simple - simply send a patch to the list that updates
|
|
the ``MAINTAINERS`` file. Sometimes this is done as part of a larger
|
|
series when a new sub-system is being added to the code base. This can
|
|
also be done by a retiring maintainer who nominates their replacement
|
|
after discussion with other contributors.
|
|
|
|
Once the patch is reviewed and merged the only other step is to make
|
|
sure your GPG key is signed.
|
|
|
|
.. _maintainer_keys:
|
|
|
|
Maintainer GPG Keys
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
GPG is used to sign pull requests so they can be identified as really
|
|
coming from the maintainer. If your key is not already signed by
|
|
members of the QEMU community, you should make arrangements to attend
|
|
a `KeySigningParty <https://wiki.qemu.org/KeySigningParty>`__ (for
|
|
example at KVM Forum) or make alternative arrangements to have your
|
|
key signed by an attendee. Key signing requires meeting another
|
|
community member **in person**\ [#2020]_ so please make appropriate
|
|
arrangements.
|
|
|
|
.. [#2020] In recent pandemic times we have had to exercise some
|
|
flexibility here. Maintainers still need to sign their pull
|
|
requests though.
|