mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-22 17:34:18 +03:00
be4047d051
The mailman for mailing lists hosted by Red Hat seems to have moved to listman.redhat.com. While the old links still seem to work, point our docs to the new location to avoid the redirect. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
92 lines
3.3 KiB
ReStructuredText
92 lines
3.3 KiB
ReStructuredText
==================
|
|
Submitting patches
|
|
==================
|
|
|
|
The simplest way to send patches is to use the
|
|
`git-publish <https://github.com/stefanha/git-publish>`__
|
|
tool. All libvirt-related repositories contain a config file
|
|
that tells git-publish to use the correct mailing list and
|
|
subject prefix.
|
|
|
|
Alternatively, you may send patches using ``git send-email``.
|
|
|
|
Also, for code motion patches, you may find that
|
|
``git diff --patience`` provides an easier-to-read
|
|
patch. However, the usual workflow of libvirt developer is:
|
|
|
|
::
|
|
|
|
$ git checkout master
|
|
$ git pull
|
|
$ git checkout -t origin -b workbranch
|
|
(hack, committing any changes along the way)
|
|
|
|
More hints on compiling can be found `here <compiling.html>`__.
|
|
Make sure to express your agreement with the `Developer Certificate
|
|
of Origin <hacking.html#developer-certificate-of-origin>`__ by
|
|
adding a "Signed-off-by" line to every commit message.
|
|
When you want to post your patches:
|
|
|
|
::
|
|
|
|
$ git pull --rebase
|
|
(fix any conflicts)
|
|
$ git send-email --cover-letter --no-chain-reply-to --annotate \
|
|
--confirm=always --to=libvir-list@redhat.com master
|
|
|
|
For a single patch you can omit ``--cover-letter``, but a
|
|
series of two or more patches needs a cover letter.
|
|
|
|
Note that the ``git send-email`` subcommand may not be in the
|
|
main git package and using it may require installation of a
|
|
separate package, for example the "git-email" package in Fedora
|
|
and Debian. If this is your first time using
|
|
``git send-email``, you might need to configure it to point it
|
|
to your SMTP server with something like:
|
|
|
|
::
|
|
|
|
$ git config --global sendemail.smtpServer stmp.youremailprovider.net
|
|
|
|
If you get tired of typing ``--to=libvir-list@redhat.com`` all
|
|
the time, you can configure that to be automatically handled as
|
|
well:
|
|
|
|
::
|
|
|
|
$ git config sendemail.to libvir-list@redhat.com
|
|
|
|
As a rule, patches should be sent to the mailing list only: all
|
|
developers are subscribed to libvir-list and read it regularly,
|
|
so **please don't CC individual developers** unless they've
|
|
explicitly asked you to.
|
|
|
|
Avoid using mail clients for sending patches, as most of them
|
|
will mangle the messages in some way, making them unusable for
|
|
our purposes. Gmail and other Web-based mail clients are
|
|
particularly bad at this.
|
|
|
|
If everything went well, your patch should show up on the
|
|
`libvir-list
|
|
archives <https://listman.redhat.com/archives/libvir-list/>`__ in a
|
|
matter of minutes; if you still can't find it on there after an
|
|
hour or so, you should double-check your setup. **Note that, if
|
|
you are not already a subscriber, your very first post to the
|
|
mailing list will be subject to moderation**, and it's not
|
|
uncommon for that to take around a day.
|
|
|
|
Please follow this as close as you can, especially the rebase
|
|
and ``git send-email`` part, as it makes life easier for other
|
|
developers to review your patch set.
|
|
|
|
One should avoid sending patches as attachments, but rather
|
|
send them in email body along with commit message. If a
|
|
developer is sending another version of the patch (e.g. to
|
|
address review comments), they are advised to note differences
|
|
to previous versions after the ``---`` line in the patch so
|
|
that it helps reviewers but doesn't become part of git history.
|
|
Moreover, such patch needs to be prefixed correctly with
|
|
``--subject-prefix=PATCHv2`` appended to
|
|
``git send-email`` (substitute ``v2`` with the
|
|
correct version if needed though).
|