diff options
| -rw-r--r-- | SUBMITTING_PATCHES | 80 |
1 files changed, 80 insertions, 0 deletions
diff --git a/SUBMITTING_PATCHES b/SUBMITTING_PATCHES new file mode 100644 index 00000000..f68906cc --- /dev/null +++ b/SUBMITTING_PATCHES | |||
| @@ -0,0 +1,80 @@ | |||
| 1 | Short Version: | ||
| 2 | |||
| 3 | - Make small logical changes. | ||
| 4 | - Provide a meaningful commit message. | ||
| 5 | - Make sure all code is under the Apache License, 2.0. | ||
| 6 | - Publish your changes for review: | ||
| 7 | |||
| 8 | git push ssh://review.source.android.com:29418/tools/repo.git HEAD:refs/for/master | ||
| 9 | |||
| 10 | |||
| 11 | Long Version: | ||
| 12 | |||
| 13 | I wanted a file describing how to submit patches for repo, | ||
| 14 | so I started with the one found in the core Git distribution | ||
| 15 | (Documentation/SubmittingPatches), which itself was based on the | ||
| 16 | patch submission guidelines for the Linux kernel. | ||
| 17 | |||
| 18 | However there are some differences, so please review and familiarize | ||
| 19 | yourself with the following relevant bits: | ||
| 20 | |||
| 21 | |||
| 22 | (1) Make separate commits for logically separate changes. | ||
| 23 | |||
| 24 | Unless your patch is really trivial, you should not be sending | ||
| 25 | out a patch that was generated between your working tree and your | ||
| 26 | commit head. Instead, always make a commit with complete commit | ||
| 27 | message and generate a series of patches from your repository. | ||
| 28 | It is a good discipline. | ||
| 29 | |||
| 30 | Describe the technical detail of the change(s). | ||
| 31 | |||
| 32 | If your description starts to get too long, that's a sign that you | ||
| 33 | probably need to split up your commit to finer grained pieces. | ||
| 34 | |||
| 35 | |||
| 36 | (2) Check the license | ||
| 37 | |||
| 38 | repo is licensed under the Apache License, 2.0. | ||
| 39 | |||
| 40 | Because of this licensing model *every* file within the project | ||
| 41 | *must* list the license that covers it in the header of the file. | ||
| 42 | Any new contributions to an existing file *must* be submitted under | ||
| 43 | the current license of that file. Any new files *must* clearly | ||
| 44 | indicate which license they are provided under in the file header. | ||
| 45 | |||
| 46 | Please verify that you are legally allowed and willing to submit your | ||
| 47 | changes under the license covering each file *prior* to submitting | ||
| 48 | your patch. It is virtually impossible to remove a patch once it | ||
| 49 | has been applied and pushed out. | ||
| 50 | |||
| 51 | |||
| 52 | (3) Sending your patches. | ||
| 53 | |||
| 54 | Do not email your patches to anyone. | ||
| 55 | |||
| 56 | Instead, login to the Gerrit Code Review tool at: | ||
| 57 | |||
| 58 | https://review.source.android.com/ | ||
| 59 | |||
| 60 | Ensure you have completed one of the necessary contributor | ||
| 61 | agreements, providing documentation to the project maintainers that | ||
| 62 | they have right to redistribute your work under the Apache License: | ||
| 63 | |||
| 64 | https://review.source.android.com/#settings,agreements | ||
| 65 | |||
| 66 | Ensure you have registered one or more SSH public keys, so you can | ||
| 67 | push your commits directly over SSH: | ||
| 68 | |||
| 69 | https://review.source.android.com/#settings,ssh-keys | ||
| 70 | |||
| 71 | Push your patches over SSH to the review server, possibly through | ||
| 72 | a remembered remote to make this easier in the future: | ||
| 73 | |||
| 74 | git config remote.review.url ssh://review.source.android.com:29418/tools/repo.git | ||
| 75 | git config remote.review.push HEAD:refs/for/master | ||
| 76 | |||
| 77 | git push review | ||
| 78 | |||
| 79 | You will be automatically emailed a copy of your commits, and any | ||
| 80 | comments made by the project maintainers. | ||
