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.
|