From befaec1e56e70582249f6cd4a5f9de5c012ad718 Mon Sep 17 00:00:00 2001 From: Mike Frysinger Date: Tue, 16 Aug 2016 00:08:37 -0400 Subject: improve docs Change-Id: Ide4008f09c2f17f8fb3d85dfffe94544abfdd6a6 --- SUBMITTING_PATCHES | 115 ----------------------------------------------------- 1 file changed, 115 deletions(-) delete mode 100644 SUBMITTING_PATCHES (limited to 'SUBMITTING_PATCHES') diff --git a/SUBMITTING_PATCHES b/SUBMITTING_PATCHES deleted file mode 100644 index 8656ee7d..00000000 --- a/SUBMITTING_PATCHES +++ /dev/null @@ -1,115 +0,0 @@ -Short Version: - - - Make small logical changes. - - Provide a meaningful commit message. - - Check for coding errors with pylint - - Make sure all code is under the Apache License, 2.0. - - Publish your changes for review. - - Make corrections if requested. - - Verify your changes on gerrit so they can be submitted. - - git push https://gerrit-review.googlesource.com/git-repo HEAD:refs/for/master - - -Long Version: - -I wanted a file describing how to submit patches for repo, -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 for coding errors with pylint - -Run pylint on changed modules using the provided configuration: - - pylint --rcfile=.pylintrc file.py - - -(3) Check the license - -repo 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. - - -(4) Sending your patches. - -Do not email your patches to anyone. - -Instead, login to the Gerrit Code Review tool at: - - https://gerrit-review.googlesource.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://gerrit-review.googlesource.com/#/settings/agreements - -Ensure you have obtained an HTTP password to authenticate: - - https://gerrit-review.googlesource.com/new-password - -Ensure that you have the local commit hook installed to automatically -add a ChangeId to your commits: - - curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://gerrit-review.googlesource.com/tools/hooks/commit-msg - chmod +x `git rev-parse --git-dir`/hooks/commit-msg - -If you have already committed your changes you will need to amend the commit -to get the ChangeId added. - - git commit --amend - -Push your patches over HTTPS to the review server, possibly through -a remembered remote to make this easier in the future: - - git config remote.review.url https://gerrit-review.googlesource.com/git-repo - 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. - - -(5) Make changes if requested - -The project maintainer who reviews your changes might request changes to your -commit. If you make the requested changes you will need to amend your commit -and push it to the review server again. - - -(6) Verify your changes on gerrit - -After you receive a Code-Review+2 from the maintainer, select the Verified -button on the gerrit page for the change. This verifies that you have tested -your changes and notifies the maintainer that they are ready to be submitted. -The maintainer will then submit your changes to the repository. -- cgit v1.2.3-54-g00ecf