diff options
Diffstat (limited to 'SUBMITTING_PATCHES')
-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. | ||