81 lines
		
	
	
		
			2.7 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			81 lines
		
	
	
		
			2.7 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| Short Version:
 | |
| 
 | |
|  - Make small logical changes.
 | |
|  - Provide a meaningful commit message.
 | |
|  - Make sure all code is under the Apache License, 2.0.
 | |
|  - Publish your changes for review:
 | |
| 
 | |
|    git push ssh://review.source.android.com:29418/tools/gerrit.git HEAD:refs/for/master
 | |
| 
 | |
| 
 | |
| Long Version:
 | |
| 
 | |
| I wanted a file describing how to submit patches for Gerrit,
 | |
| so I started with the one found in the core Git distribution
 | |
| (Documentation/SubmittingPatches), which itself was based on the
 | |
| patch submission guidelines for the Linux kernel.
 | |
| 
 | |
| However there are some differences, so please review and familiarize
 | |
| yourself with the following relevant bits:
 | |
| 
 | |
| 
 | |
| (1) Make separate commits for logically separate changes.
 | |
| 
 | |
| Unless your patch is really trivial, you should not be sending
 | |
| out a patch that was generated between your working tree and your
 | |
| commit head.  Instead, always make a commit with complete commit
 | |
| message and generate a series of patches from your repository.
 | |
| It is a good discipline.
 | |
| 
 | |
| Describe the technical detail of the change(s).
 | |
| 
 | |
| If your description starts to get too long, that's a sign that you
 | |
| probably need to split up your commit to finer grained pieces.
 | |
| 
 | |
| 
 | |
| (2) Check the license
 | |
| 
 | |
| Gerrit Code Review is licensed under the Apache License, 2.0.
 | |
| 
 | |
| Because of this licensing model *every* file within the project
 | |
| *must* list the license that covers it in the header of the file.
 | |
| Any new contributions to an existing file *must* be submitted under
 | |
| the current license of that file.  Any new files *must* clearly
 | |
| indicate which license they are provided under in the file header.
 | |
| 
 | |
| Please verify that you are legally allowed and willing to submit your
 | |
| changes under the license covering each file *prior* to submitting
 | |
| your patch.  It is virtually impossible to remove a patch once it
 | |
| has been applied and pushed out.
 | |
| 
 | |
| 
 | |
| (3) Sending your patches.
 | |
| 
 | |
| Do not email your patches to anyone.
 | |
| 
 | |
| Instead, login to the Gerrit Code Review tool at:
 | |
| 
 | |
|   https://review.source.android.com/
 | |
| 
 | |
| Ensure you have completed one of the necessary contributor
 | |
| agreements, providing documentation to the project maintainers that
 | |
| they have right to redistribute your work under the Apache License:
 | |
| 
 | |
|   https://review.source.android.com/#settings,agreements
 | |
| 
 | |
| Ensure you have registered one or more SSH public keys, so you can
 | |
| push your commits directly over SSH:
 | |
| 
 | |
|   https://review.source.android.com/#settings,ssh-keys
 | |
| 
 | |
| Push your patches over SSH to the review server, possibly through
 | |
| a remembered remote to make this easier in the future:
 | |
| 
 | |
|    git config remote.review.url ssh://review.source.android.com:29418/tools/gerrit.git
 | |
|    git config remote.review.push HEAD:refs/for/master
 | |
| 
 | |
|    git push review
 | |
| 
 | |
| You will be automatically emailed a copy of your commits, and any
 | |
| comments made by the project maintainers.
 | 
