77 lines
3.1 KiB
ReStructuredText
77 lines
3.1 KiB
ReStructuredText
Submitting a Patch
|
||
##################
|
||
|
||
Read the following information carefully before submitting a patch. It
|
||
applies for developers that are new to open source as well as for
|
||
experienced open source developers.
|
||
|
||
New to Open Source?
|
||
*******************
|
||
|
||
Welcome to open source software development. Whether you are an
|
||
experienced developer within a corporate environment, a beginner trying
|
||
out something new or someone in between, we thank you for your interest
|
||
in the development of Tiny Mountain.
|
||
|
||
Before you begin we suggest you read the `Patch Philosophy`_.
|
||
|
||
.. _`Patch Philosophy`: http://kernelnewbies.org/PatchPhilosophy
|
||
|
||
Be sure to read the documentation before submitting any patches.
|
||
|
||
It is of great importance that each patch includes a Signed-off-by line,
|
||
containing your full legal name. Adding your Signed-off-by line means
|
||
you assert this patch meets the legal requirements of the
|
||
`developer certificate of origin`_. Read and understand that document
|
||
before contributing code or documentation to the project.
|
||
|
||
.. _`developer certificate of origin`: http://developercertificate.org/
|
||
|
||
Patch Requirements
|
||
******************
|
||
|
||
Here you can find the required format and content for patches. For more
|
||
information on how to submit a patch using Gerrit please refer to
|
||
`Submitting a Patch Via Gerrit`_.
|
||
|
||
Each patch must contain a short descriptive subject line, typically less
|
||
than 72 characters, a patch description, and a Signed-off-by line. A
|
||
patch with all three is considered well formed. A patch set must have
|
||
all three plus a cover letter to be considered well formed.
|
||
|
||
All patches and patch sets sent to Gerrit must be well formed. Commit
|
||
messages must include “what” the patch does, “why” you chose that
|
||
approach, what assumptions you made and “how” you know it works, for
|
||
example, which tests you’ve run.
|
||
|
||
|
||
Commits must build cleanly when applied in top of each other, thus
|
||
avoiding breaking bisectability. Commits must pass the
|
||
:file:`scripts/checkpatch.pl` requirements. For more details see the
|
||
:ref:`Coding` section. Each commit must address a single identifiable
|
||
issue and must be logically self contained.
|
||
|
||
For example: One commit fixes whitespace issues, another renames a
|
||
function and a third one changes the code's functionality.
|
||
|
||
Every commit must contain the following line at the bottom of the commit
|
||
message:
|
||
|
||
Signed-off-by: your@email.address
|
||
|
||
The name in the Signed-off-by line and your email must match the patch
|
||
authorship information. Make sure your *.git/config* is set up
|
||
correctly. Always submit the full patchset via Gerrit.
|
||
|
||
When a patch is included in the set to enable the other patches but it
|
||
will not be part of the final set, let the reviewers know this. Use
|
||
requests for comment (RFCs) to send work proposals, progress snapshots
|
||
of your work or to get early feedback on features or changes that will
|
||
affect multiple areas in the code.
|
||
|
||
Before you submit, please ensure each of your commits conforms with the
|
||
coding and contribution guidelines of the project found in
|
||
`Patch Requirements`_.
|
||
|
||
If you are submitting a patch that has someone else's Signed-off-by make
|
||
sure that you include that person as a Reviewer in Gerrit. |