Update "submitting-patches.asciidoc" for the move to gitlab
Also include a section encouraging discussion of large changes as there have been a number of case of rejected features being reinvented. Fixes #34 Signed-off-by: Allan McRae <allan@archlinux.org>
This commit is contained in:
parent
f74daa39e8
commit
fface9001a
@ -23,6 +23,21 @@ The pacman code can be fetched using the following command:
|
|||||||
git clone https://gitlab.archlinux.org/pacman/pacman.git
|
git clone https://gitlab.archlinux.org/pacman/pacman.git
|
||||||
|
|
||||||
|
|
||||||
|
Before making large changes
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
--
|
||||||
|
* Discuss your idea
|
||||||
|
|
||||||
|
There is nothing worse that spending time making a change only for it to be
|
||||||
|
rejected immediately. Ensure ideas are discussed beforehand to avoid
|
||||||
|
disappointment. Appropriate locations for discussion are the issue tracker
|
||||||
|
on gitlab, or the pacman-dev mailing list. Transient discussion channels
|
||||||
|
such as IRC are not appropriate.
|
||||||
|
|
||||||
|
--
|
||||||
|
|
||||||
|
|
||||||
Creating your patch
|
Creating your patch
|
||||||
-------------------
|
-------------------
|
||||||
|
|
||||||
@ -43,36 +58,18 @@ It helps if you describe the overview and goals of the patch in the git commit
|
|||||||
log. This allows others to see what you intended so as to compare it to what
|
log. This allows others to see what you intended so as to compare it to what
|
||||||
was actually done, and allows better feedback.
|
was actually done, and allows better feedback.
|
||||||
|
|
||||||
* Use `git format-patch` to create patches.
|
|
||||||
|
|
||||||
Your commit message will be shown above the patch by default when you will use
|
|
||||||
`git format-patch`, including the signoff line. Sets of multiple patches that
|
|
||||||
need extra explanation beyond the commit messages may include additional notes
|
|
||||||
in a cover letter. Individual patches may include additional notes between the
|
|
||||||
"---" following the commit message and the beginning of the diff.
|
|
||||||
|
|
||||||
--
|
--
|
||||||
|
|
||||||
Submitting your patch
|
Submitting your patch
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
--
|
--
|
||||||
* Send the patch to the pacman-dev mailing list
|
* Submit patches with a gitlab merge request
|
||||||
|
|
||||||
The mailing list is the primary queue for review and acceptance. Here you
|
The pacman gitlab instance is the primary queue for review and acceptance.
|
||||||
will get feedback, and let the reviewers know the details of your patch.
|
Here you will get feedback, and let the reviewers know the details of your
|
||||||
|
patch.
|
||||||
|
|
||||||
* No MIME, no links, no compression, no attachments. Just plain text.
|
|
||||||
|
|
||||||
Patches should be contained in the actual body of the email. There are many
|
|
||||||
reasons for this. First, it makes them easier to read with any mail reader,
|
|
||||||
it allows easier review "at a glance", and most importantly, it allows people
|
|
||||||
to comment on exact lines of the patch in reply emails.
|
|
||||||
|
|
||||||
`git send-email` allows you to send Git-formatted patches in plain text easily
|
|
||||||
and is the preferred method for submission to the mailing list. Mail clients,
|
|
||||||
including Gmail's web interface, have a tendency to break patches by wrapping
|
|
||||||
lines and/or adjusting whitespace and should be avoided.
|
|
||||||
|
|
||||||
--
|
--
|
||||||
|
|
||||||
@ -95,7 +92,6 @@ When you do get feedback, it usually merits a response, whether this be a
|
|||||||
resubmission of the patch with corrections or a follow-up email asking for
|
resubmission of the patch with corrections or a follow-up email asking for
|
||||||
clarifications. When neither of these occurs, don't expect your patch to get
|
clarifications. When neither of these occurs, don't expect your patch to get
|
||||||
further review. The all-volunteer staff don't have time to fix up patches that
|
further review. The all-volunteer staff don't have time to fix up patches that
|
||||||
aren't their own. When resubmitting patches, update the subject line to reflect
|
aren't their own.
|
||||||
the version number ('[PATCHv2]'), and send it as a reply to the original thread.
|
|
||||||
|
|
||||||
--
|
--
|
||||||
|
Loading…
Reference in New Issue
Block a user