32 lines
1.3 KiB
Plaintext
32 lines
1.3 KiB
Plaintext
|
Patches are preferably to be sent via a github pull request. If that
|
||
|
|
can't be done, patches in "git format-patch" format can be sent
|
||
|
|
(eg, posted to fpaste.org with a long enough timeout and a link
|
||
|
|
posted to #monero-dev on irc.freenode.net).
|
||
|
|
|
||
|
|
Patches should be self contained. A good rule of thumb is to have
|
||
|
|
one patch per separate issue, feature, or logical change. Also, no
|
||
|
|
other changes, such as random whitespace changes or reindentation.
|
||
|
|
Following the code style of the particular chunk of code you're
|
||
|
|
modifying is encourgaged. Proper squashing should be done (eg, if
|
||
|
|
you're making a buggy patch, then a later patch to fix the bug,
|
||
|
|
both patches should be merged).
|
||
|
|
|
||
|
|
Commit messages should be sensible. That means a subject line that
|
||
|
|
describes the patch, with an optional longer body that gives details,
|
||
|
|
documentation, etc.
|
||
|
|
|
||
|
|
Comments are encouraged.
|
||
|
|
|
||
|
|
If modifying code for which Doxygen headers exist, that header must
|
||
|
|
be modified to match.
|
||
|
|
|
||
|
|
When submitting a pull request on github, make sure your branch is
|
||
|
|
rebased. No merge commits nor stray commits from other people in
|
||
|
|
your submitted branch, please. You may be asked to rebase if there
|
||
|
|
are conflicts (even trivially resolvable ones).
|
||
|
|
|
||
|
|
PGP signing commits is strongly encouraged. That should explain why
|
||
|
|
the previous paragraph is here.
|
||
|
|
|
||
|
|
Tests would be nice to have if you're adding functionality.
|