github.com/nf/docker@v1.8.1/docs/project/review-pr.md (about)

     1  <!--[metadata]>
     2  +++
     3  title = "Participate in the PR review"
     4  description = "Basic workflow for Docker contributions"
     5  keywords = ["contribute, pull request, review, workflow, beginner, squash,  commit"]
     6  [menu.main]
     7  parent = "smn_contribute"
     8  weight=5
     9  +++
    10  <![end-metadata]-->
    11  
    12  
    13  # Participate in the PR review
    14  
    15  Creating a pull request is nearly the end of the contribution process. At this
    16  point, your code is reviewed both by our continuous integration (CI) systems and
    17  by our maintainers. 
    18  
    19  The CI system is an automated system. The maintainers are human beings that also
    20  work on Docker.  You need to understand and work with both the "bots" and the
    21  "beings" to review your contribution.
    22  
    23  
    24  ## How we process your review
    25  
    26  First to review your pull request is Gordon. Gordon is fast. He checks your
    27  pull request (PR) for common problems like a missing signature. If Gordon finds a
    28  problem, he'll send an email through your GitHub user account:
    29  
    30  ![Gordon](/project/images/gordon.jpeg)
    31  
    32  Our build bot system starts building your changes while Gordon sends any emails. 
    33  
    34  The build system double-checks your work by compiling your code with Docker's master
    35  code. Building includes running the same tests you ran locally. If you forgot
    36  to run tests or missed something in fixing problems, the automated build is our
    37  safety check. 
    38  
    39  After Gordon and the bots, the "beings" review your work. Docker maintainers look
    40  at your pull request and comment on it. The shortest comment you might see is
    41  `LGTM` which means **l**ooks-**g**ood-**t**o-**m**e. If you get an `LGTM`, that
    42  is a good thing, you passed that review. 
    43  
    44  For complex changes, maintainers may ask you questions or ask you to change
    45  something about your submission. All maintainer comments on a PR go to the
    46  email address associated with your GitHub account. Any GitHub user who 
    47  "participates" in a PR receives an email to. Participating means creating or 
    48  commenting on a PR.
    49  
    50  Our maintainers are very experienced Docker users and open source contributors.
    51  So, they value your time and will try to work efficiently with you by keeping
    52  their comments specific and brief. If they ask you to make a change, you'll
    53  need to update your pull request with additional changes.
    54  
    55  ## Update an existing pull request
    56  
    57  To update your existing pull request:
    58  
    59  1. Checkout the PR branch in your local `docker-fork` repository.  
    60  
    61      This is the branch associated with your request.
    62  
    63  2. Change one or more files and then stage your changes.
    64  
    65      The command syntax is:
    66  
    67      	git add <path_or_filename>
    68  
    69  3. Commit the change.
    70  
    71      	$ git commit --amend 
    72  
    73      Git opens an editor containing your last commit message.
    74  
    75  4. Adjust your last comment to reflect this new change.
    76  
    77          Added a new sentence per Anaud's suggestion	
    78  
    79          Signed-off-by: Mary Anthony <mary@docker.com>
    80  
    81          # Please enter the commit message for your changes. Lines starting
    82          # with '#' will be ignored, and an empty message aborts the commit.
    83          # On branch 11038-fix-rhel-link
    84          # Your branch is up-to-date with 'origin/11038-fix-rhel-link'.
    85          #
    86          # Changes to be committed:
    87          #		modified:   docs/installation/mac.md
    88          #		modified:   docs/installation/rhel.md
    89  
    90  5. Force push the change to your origin.
    91  
    92      The command syntax is:
    93  
    94          git push -f origin <branch_name>
    95  
    96  6. Open your browser to your pull request on GitHub.
    97  
    98      You should see your pull request now contains your newly pushed code.
    99  
   100  7. Add a comment to your pull request.
   101  
   102      GitHub only notifies PR participants when you comment. For example, you can
   103      mention that you updated your PR. Your comment alerts the maintainers that
   104      you made an update.
   105  
   106  A change requires LGTMs from an absolute majority of an affected component's
   107  maintainers. For example, if you change `docs/` and `registry/` code, an
   108  absolute majority of the `docs/` and the `registry/` maintainers must approve
   109  your PR. Once you get approval, we merge your pull request into Docker's 
   110  `master` code branch. 
   111  
   112  ## After the merge
   113  
   114  It can take time to see a merged pull request in Docker's official release. 
   115  A master build is available almost immediately though. Docker builds and
   116  updates its development binaries after each merge to `master`.
   117  
   118  1. Browse to <a href="https://master.dockerproject.org/" target="_blank">https://master.dockerproject.org/</a>.
   119  
   120  2. Look for the binary appropriate to your system.
   121  
   122  3. Download and run the binary.
   123  
   124      You might want to run the binary in a container though. This
   125      will keep your local host environment clean.
   126  
   127  4. View any documentation changes at <a href="http://docs.master.dockerproject.org/" target="_blank">docs.master.dockerproject.org</a>. 
   128  
   129  Once you've verified everything merged, feel free to delete your feature branch
   130  from your fork. For information on how to do this, 
   131  <a href="https://help.github.com/articles/deleting-unused-branches/" target="_blank">
   132  see the GitHub help on deleting branches</a>.  
   133  
   134  ## Where to go next
   135  
   136  At this point, you have completed all the basic tasks in our contributors guide.
   137  If you enjoyed contributing, let us know by completing another beginner
   138  issue or two. We really appreciate the help. 
   139  
   140  If you are very experienced and want to make a major change, go on to 
   141  [learn about advanced contributing](/project/advanced-contributing).