github.com/torfuzx/docker@v1.8.1/docs/project/coding-style.md (about)

     1  <!--[metadata]>
     2  +++
     3  title = "Coding style checklist"
     4  description = "List of guidelines for coding Docker contributions"
     5  keywords = ["change, commit, squash, request, pull request, test, unit test, integration tests, Go, gofmt,  LGTM"]
     6  [menu.main]
     7  parent = "smn_contribute"
     8  weight=7
     9  +++
    10  <![end-metadata]-->
    11  
    12  # Coding style checklist
    13  
    14  This checklist summarizes the material you experienced working through [make a
    15  code contribution](/project/make-a-contribution) and [advanced
    16  contributing](/project/advanced-contributing). The checklist applies to both 
    17  program code and documentation code.
    18  
    19  ## Change and commit code
    20  
    21  * Fork the `docker/docker` repository.
    22  
    23  * Make changes on your fork in a feature branch. Name your branch `XXXX-something`
    24    where `XXXX` is the issue number you are working on.
    25  
    26  * Run `gofmt -s -w file.go` on each changed file before
    27    committing your changes. Most editors have plug-ins that do this automatically.
    28  
    29  * Run `golint` on each changed file before
    30    committing your changes.
    31  
    32  * Update the documentation when creating or modifying features. 
    33  
    34  * Commits that fix or close an issue should reference them in the commit message
    35    `Closes #XXXX` or `Fixes #XXXX`. Mentions help by automatically closing the
    36    issue on a merge.
    37  
    38  * After every commit, run the test suite and ensure it is passing.
    39  
    40  * Sync and rebase frequently as you code to keep up with `docker` master.
    41  
    42  * Set your `git` signature and make sure you sign each commit.
    43  
    44  * Do not add yourself to the `AUTHORS` file. This file is autogenerated from the
    45    Git history.
    46  
    47  ## Tests and testing
    48  
    49  * Submit unit tests for your changes. 
    50  
    51  * Make use of the builtin Go test framework built. 
    52  
    53  * Use existing Docker test files (`name_test.go`) for inspiration. 
    54  
    55  * Run <a href="../test-and-docs" target="_blank">the full test suite</a> on your
    56    branch before submitting a pull request.
    57  
    58  * Run `make docs` to build the documentation and then check it locally.
    59  
    60  * Use an <a href="http://www.hemingwayapp.com" target="_blank">online grammar
    61    checker</a> or similar to test you documentation changes for clarity,
    62    concision, and correctness.
    63  
    64  ## Pull requests
    65  
    66  * Sync and cleanly rebase on top of Docker's `master` without multiple branches
    67    mixed into the PR.
    68  
    69  * Before the pull request, squash your commits into logical units of work using
    70    `git rebase -i` and `git push -f`. 
    71  
    72  * Include documentation changes in the same commit so that a revert would
    73    remove all traces of the feature or fix.
    74  
    75  * Reference each issue in your pull request description (`#XXXX`)
    76  
    77  ## Respond to pull requests reviews 
    78  
    79  * Docker maintainers use LGTM (**l**ooks-**g**ood-**t**o-**m**e) in PR comments
    80    to indicate acceptance.
    81  
    82  * Code review comments may be added to your pull request. Discuss, then make
    83    the suggested modifications and push additional commits to your feature
    84    branch.
    85  
    86  * Incorporate changes on your feature branch and push to your fork. This
    87    automatically updates your open pull request.
    88  
    89  * Post a comment after pushing to alert reviewers to PR changes; pushing a
    90    change does not send notifications.
    91  
    92  * A change requires LGTMs from an absolute majority maintainers of an
    93    affected component. For example, if you change `docs/` and `registry/` code,
    94    an absolute majority of the `docs/` and the `registry/` maintainers must
    95    approve your PR.
    96  
    97  ## Merges after pull requests
    98  
    99  * After a merge, [a master build](https://master.dockerproject.org/) is
   100    available almost immediately.
   101  
   102  * If you made a documentation change, you can see it at
   103    [docs.master.dockerproject.org](http://docs.master.dockerproject.org/).