1. docker
  2. Commit efc625fcd00b0f76e484d0bc081bafcfd789cfbb
Browse code

Cleanup: new project docs fix-ups (alternative)

This cleans up the recently added project docs and
fixes some minor issues.

- remove inline styles where possible
- add redirects for renamed/replaced documents
- add styles for GitHub labels to match the style on GitHub
- fix minor markdown issues causing some code-blocks
to be shown as text
- wrap the documents to 80-chars
- use 4 spaces in stead of tabs for identing and remove
trailing whitespace/redundant blank lines
- optimized 'gordon' image

NOTE:
This alternative commit/PR re-introduces some inline
styles because the docs/base image has not yet been
updated for the current docs.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

Sebastiaan van Stijn authored on 2015/03/07 22:06:40
Showing 11 changed files
docs/s3_website.json
History View file @ efc625f
... ... 
@@ -36,7 +36,10 @@
36 36 
     { "Condition": { "KeyPrefixEquals": "examples/using_supervisord/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "articles/using_supervisord/" } },
37 37 
     { "Condition": { "KeyPrefixEquals": "reference/api/registry_index_spec/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "reference/api/hub_registry_spec/" } },
38 38 
     { "Condition": { "KeyPrefixEquals": "use/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "examples/" } },
39 
-    { "Condition": { "KeyPrefixEquals": "installation/openSUSE/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "installation/SUSE/" } }
39 
+    { "Condition": { "KeyPrefixEquals": "installation/openSUSE/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "installation/SUSE/" } },
40 
+    { "Condition": { "KeyPrefixEquals": "contributing/contributing/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "project/who-written-for/" } },
41 
+    { "Condition": { "KeyPrefixEquals": "contributing/devenvironment/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "project/set-up-prereqs/" } },
42 
+    { "Condition": { "KeyPrefixEquals": "contributing/docs_style-guide/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "project/doc-style/" } }
40 43 
   ]
41 44 
 }
42 45
docs/sources/project/advanced-contributing.md
History View file @ efc625f
... ... 
@@ -4,15 +4,23 @@ page_keywords: contribute, project, design, refactor, proposal
4 4
5 5 
 # Advanced contributing
6 6
7 
-In this section, you learn about the more advanced contributions you can make. They are advanced because they have a more involved workflow or require greater programming experience. Don't be scared off though, if you like to stretch and challenge yourself, this is the place for you.
7 
+In this section, you learn about the more advanced contributions you can make.
8 
+They are advanced because they have a more involved workflow or require greater
9 
+programming experience. Don't be scared off though, if you like to stretch and
10 
+challenge yourself, this is the place for you.
8 11
9 
-This section gives generalized instructions for advanced contributions. You'll read about the workflow but there are not specific descriptions of commands. Your goal should be to understand the processes described.
12 
+This section gives generalized instructions for advanced contributions. You'll
13 
+read about the workflow but there are not specific descriptions of commands.
14 
+Your goal should be to understand the processes described.
10 15
11 
-At this point, you should have read and worked through the earlier parts of the project contributor guide. You should also have <a href="../make-a-contribution" target="_blank"> made at least one project contribution</a>.
16 
+At this point, you should have read and worked through the earlier parts of
17 
+the project contributor guide. You should also have
18 
+<a href="../make-a-contribution/" target="_blank"> made at least one project contribution</a>.
12 19
13 20 
 ## Refactor or cleanup proposal
14 21
15 
-A refactor or cleanup proposal changes Docker's internal structure without altering the external behavior. To make this type of proposal:
22 
+A refactor or cleanup proposal changes Docker's internal structure without
23 
+altering the external behavior. To make this type of proposal:
16 24
17 25 
 1. Fork `docker/docker`.
18 26
... ... 
@@ -24,31 +32,36 @@ A refactor or cleanup proposal changes Docker's internal structure without alter
24 24
25 25 
 4. Submit your code through a pull request (PR).
26 26
27 
-	The PR's title should have the format:
28 
-
29 
-	**Cleanup:** _short title_
30 
-
31 
-	If your changes required logic changes, note that in your request.
27 
+    The PR's title should have the format:
28 
+
29 
+    **Cleanup:** _short title_
30 
+
31 
+    If your changes required logic changes, note that in your request.
32 32
33 33 
 5. Work through Docker's review process until merge.
34 34
35 35
36 36 
 ## Design proposal
37 37
38 
-A design proposal solves a problem or adds a feature to the Docker software. The process for submitting design proposals requires two pull requests, one for the design and one for the implementation.
38 
+A design proposal solves a problem or adds a feature to the Docker software.
39 
+The process for submitting design proposals requires two pull requests, one
40 
+for the design and one for the implementation.
39 41
40 42 
 ![Simple process](/project/images/proposal.png)
41 43
42 
-The important thing to notice is that both the design pull request and the implementation pull request go through a review. In other words, there is considerable time commitment in a design proposal; so, you might want to pair with someone on design work.
44 
+The important thing to notice is that both the design pull request and the
45 
+implementation pull request go through a review. In other words, there is
46 
+considerable time commitment in a design proposal; so, you might want to pair
47 
+with someone on design work.
43 48
44 49 
 The following provides greater detail on the process:
45 50
46 51 
 1. Come up with an idea.
47 52
48 
-	Ideas usually come from limitations users feel working with a product. So,
49 
-	take some time to really use Docker. Try it on different platforms; explore
50 
-	how it works with different web applications. Go to some community events
51 
-	and find out what other users want.
53 
+    Ideas usually come from limitations users feel working with a product. So,
54 
+    take some time to really use Docker. Try it on different platforms; explore
55 
+    how it works with different web applications. Go to some community events
56 
+    and find out what other users want.
52 57
53 58 
 2. Review existing issues and proposals to make sure no other user is proposing a similar idea.
54 59
... ... 
@@ -58,69 +71,69 @@ The following provides greater detail on the process:
58 58
59 59 
 3. Talk to the community about your idea.
60 60
61 
-	We have lots of <a href="../get-help" target="_blank">community forums</a>
62 
-	where you can get feedback on your idea. Float your idea in a forum or two
63 
-	to get some commentary going on it.
64 
-
61 
+    We have lots of <a href="../get-help/" target="_blank">community forums</a>
62 
+    where you can get feedback on your idea. Float your idea in a forum or two
63 
+    to get some commentary going on it.
64 
+
65 65 
 4. Fork `docker/docker` and clone the repo to your local host.
66 66
67 67 
 5. Create a new Markdown file in the area you wish to change.
68 68
69 
-	For example, if you want to redesign our daemon create a new file under the
70 
-	`daemon/` folder.
69 
+    For example, if you want to redesign our daemon create a new file under the
70 
+    `daemon/` folder.
71 
+
72 
+6. Name the file descriptively, for example `redesign-daemon-proposal.md`.
71 73
72 
-6. Name the file descriptively, for example `redesign-daemon-proposal.md`.
73 
-
74 74 
 7. Write a proposal for your change into the file.
75 75
76 
-	This is a markdown file that describes your idea. Your proposal
77 
-	should include information like:
78 
-
79 
-	* Why is this changed needed or what are the use cases?
80 
-	* What are the requirements this change should meet?
81 
-	* What are some ways to design/implement this feature?
82 
-	* Which design/implementation do you think is best and why?
83 
-	* What are the risks or limitations of your proposal?
84 
-
85 
-	 This is your chance to convince people your idea is sound.
86 
-
76 
+    This is a Markdown file that describes your idea. Your proposal
77 
+    should include information like:
78 
+
79 
+    * Why is this changed needed or what are the use cases?
80 
+    * What are the requirements this change should meet?
81 
+    * What are some ways to design/implement this feature?
82 
+    * Which design/implementation do you think is best and why?
83 
+    * What are the risks or limitations of your proposal?
84 
+
85 
+    This is your chance to convince people your idea is sound.
86 
+
87 87 
 8. Submit your proposal in a pull request to `docker/docker`.
88 88
89 
-	The title should have the format:
90 
-
91 
-	**Proposal:** _short title_
92 
-
93 
-	The body of the pull request should include a brief summary of your change
94 
-	and then say something like "_See the file for a complete description_".
95 
-
89 
+    The title should have the format:
90 
+
91 
+    **Proposal:** _short title_
92 
+
93 
+    The body of the pull request should include a brief summary of your change
94 
+    and then say something like "_See the file for a complete description_".
95 
+
96 96 
 9. Refine your proposal through review.
97 97
98 
-	The maintainers and the community review your proposal. You'll need to
99 
-	answer questions and sometimes explain or defend your approach. This is
100 
-	chance for everyone to both teach and learn.
101 
-
98 
+    The maintainers and the community review your proposal. You'll need to
99 
+    answer questions and sometimes explain or defend your approach. This is
100 
+    chance for everyone to both teach and learn.
101 
+
102 102 
 10. Pull request accepted.
103 103
104 
-	Your request may also be rejected. Not every idea is a good fit for Docker.
105 
-	Let's assume though your proposal succeeded.
106 
-
104 
+    Your request may also be rejected. Not every idea is a good fit for Docker.
105 
+    Let's assume though your proposal succeeded.
106 
+
107 107 
 11. Implement your idea.
108 108
109 
-	Implementation uses all the standard practices of any contribution.
110 
-
111 
-	 * fork `docker/docker`
112 
-	 * create a feature branch
113 
-	 * sync frequently back to master
114 
-	 * test as you go and full test before a PR
115 
-
116 
-	 If you run into issues, the community is there to help.
117 
-
109 
+    Implementation uses all the standard practices of any contribution.
110 
+
111 
+    * fork `docker/docker`
112 
+    * create a feature branch
113 
+    * sync frequently back to master
114 
+    * test as you go and full test before a PR
115 
+
116 
+    If you run into issues, the community is there to help.
117 
+
118 118 
 12. When you have a complete implementation, submit a pull request back to `docker/docker`.
119 119
120 120 
 13. Review and iterate on your code.
121 121
122 
-	If you are making a large code change, you can expect greater scrutiny
123 
-	during this phase.
124 
-
122 
+    If you are making a large code change, you can expect greater scrutiny
123 
+    during this phase.
124 
+
125 125 
 14. Acceptance and merge!
126 126
docs/sources/project/coding-style.md
History View file @ efc625f
... ... 
@@ -4,22 +4,26 @@ page_keywords: change, commit, squash, request, pull request, test, unit test, i
4 4
5 5 
 # Coding Style Checklist
6 6
7 
-This checklist summarizes the material you experienced working through [make a code contribution](/project/make-a-contribution) and [advanced contributing](/project/advanced-contributing).  The checklist applies to code that is program code or code that is documentation code.
7 
+This checklist summarizes the material you experienced working through [make a
8 
+code contribution](/project/make-a-contribution) and [advanced
9 
+contributing](/project/advanced-contributing). The checklist applies to code
10 
+that is program code or code that is documentation code.
8 11
9 12 
 ## Change and commit code
10 13
11 14 
 * Fork the `docker/docker` repository.
12 15
13 
-* Make changes on your fork in a feature branch. Name your branch `XXXX-something` where `XXXX` is the issue number you are working on.
16 
+* Make changes on your fork in a feature branch. Name your branch `XXXX-something`
17 
+  where `XXXX` is the issue number you are working on.
14 18
15 19 
 * Run `gofmt -s -w file.go` on each changed file before
16 
-committing your changes. Most editors have plug-ins that do this automatically.
20 
+  committing your changes. Most editors have plug-ins that do this automatically.
17 21
18 22 
 * Update the documentation when creating or modifying features.
19 23
20 24 
 * Commits that fix or close an issue should reference them in the commit message
21 
-`Closes #XXXX` or `Fixes #XXXX`. Mentions help by automatically closing the
22 
-issue on a merge.
25 
+  `Closes #XXXX` or `Fixes #XXXX`. Mentions help by automatically closing the
26 
+  issue on a merge.
23 27
24 28 
 * After every commit, run the test suite and ensure it is passing.
25 29
... ... 
@@ -27,7 +31,8 @@ issue on a merge.
27 27
28 28 
 * Set your `git` signature and make sure you sign each commit.
29 29
30 
-* Do not add yourself to the `AUTHORS` file. This file is autogenerated from the Git history.
30 
+* Do not add yourself to the `AUTHORS` file. This file is autogenerated from the
31 
+  Git history.
31 32
32 33 
 ## Tests and testing
33 34
... ... 
@@ -37,40 +42,52 @@ issue on a merge.
37 37
38 38 
 * Use existing Docker test files (`name_test.go`) for inspiration.
39 39
40 
-* Run <a href="../test-and-docs" target="_blank">the full test suite</a> on your branch before submitting a pull request.
40 
+* Run <a href="../test-and-docs" target="_blank">the full test suite</a> on your
41 
+  branch before submitting a pull request.
41 42
42 43 
 * Run `make docs` to build the documentation and then check it locally.
43 44
44 45 
 * Use an <a href="http://www.hemingwayapp.com" target="_blank">online grammar
45 
-checker</a> or similar to test you documentation changes for clarity, concision,
46 
-and correctness.
46 
+  checker</a> or similar to test you documentation changes for clarity,
47 
+  concision, and correctness.
47 48
48 49 
 ## Pull requests
49 50
50 51 
 * Sync and cleanly rebase on top of Docker's `master` without multiple branches
51 
-mixed into the PR.
52 
+  mixed into the PR.
52 53
53 
-* Before the pull request, squash your commits into logical units of work using `git rebase -i` and `git push -f`.
54 
+* Before the pull request, squash your commits into logical units of work using
55 
+  `git rebase -i` and `git push -f`.
54 56
55 
-* Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
57 
+* Include documentation changes in the same commit so that a revert would
58 
+  remove all traces of the feature or fix.
56 59
57 60 
 * Reference each issue in your pull request description (`#XXXX`)
58 61
59 62 
 ## Respond to pull requests reviews
60 63
61 
-* Docker maintainers use LGTM (**l**ooks-**g**ood-**t**o-**m**e) in PR comments to indicate acceptance.
64 
+* Docker maintainers use LGTM (**l**ooks-**g**ood-**t**o-**m**e) in PR comments
65 
+  to indicate acceptance.
62 66
63 
-* Code review comments may be added to your pull request. Discuss, then make the
64 
-suggested modifications and push additional commits to your feature branch.
67 
+* Code review comments may be added to your pull request. Discuss, then make
68 
+  the suggested modifications and push additional commits to your feature
69 
+  branch.
65 70
66 
-* Incorporate changes on your feature branch and push to your fork. This automatically updates your open pull request.
71 
+* Incorporate changes on your feature branch and push to your fork. This
72 
+  automatically updates your open pull request.
67 73
68 
-* Post a comment after pushing to alert reviewers to PR changes; pushing a change does not send notifications.
74 
+* Post a comment after pushing to alert reviewers to PR changes; pushing a
75 
+  change does not send notifications.
69 76
70 
-* A change requires LGTMs from an absolute majority maintainers of an affected component. For example, if you change `docs/` and `registry/` code, an absolute majority of the `docs/` and the `registry/` maintainers must approve your PR.
77 
+* A change requires LGTMs from an absolute majority maintainers of an
78 
+  affected component. For example, if you change `docs/` and `registry/` code,
79 
+  an absolute majority of the `docs/` and the `registry/` maintainers must
80 
+  approve your PR.
71 81
72 82 
 ## Merges after pull requests
73 83
74 
-* After a merge, [a master build](https://master.dockerproject.com/) is available almost immediately.
84 
+* After a merge, [a master build](https://master.dockerproject.com/) is
85 
+  available almost immediately.
75 86
76 
-* If you made a documentation change, you can see it at [docs.master.dockerproject.com](http://docs.master.dockerproject.com/).
87 
+* If you made a documentation change, you can see it at
88 
+  [docs.master.dockerproject.com](http://docs.master.dockerproject.com/).
docs/sources/project/doc-style.md
History View file @ efc625f
... ... 
@@ -214,7 +214,7 @@ exactly what they see in their shell:
214 214
215 215 
 * Indent shell examples by 4 spaces so they get rendered as code blocks.
216 216 
 * Start typed commands with `$ ` (dollar space), so that they are easily
217 
-differentiated from program output.
217 
+  differentiated from program output.
218 218 
 * Program output has no prefix.
219 219 
 * Comments begin with # (hash space).
220 220 
 * In-container shell commands, begin with `$$ ` (dollar dollar space).
... ... 
@@ -232,7 +232,7 @@ following:
232 232 
 * Point out potential issues or questions
233 233 
 * Ask for help from experts in the company or the community
234 234 
 * Encourage feedback from core developers and others involved in creating the
235 
-software being documented.
235 
+  software being documented.
236 236
237 237 
 Writing a PR that is singular in focus and has clear objectives will encourage
238 238 
 all of the above. Done correctly, the process allows reviewers (maintainers and
docs/sources/project/get-help.md
History View file @ efc625f
... ... 
@@ -2,103 +2,138 @@ page_title: Where to chat or get help
2 2 
 page_description: Describes Docker's communication channels
3 3 
 page_keywords: IRC, Google group, Twitter, blog, Stackoverflow
4 4
5 
+<style>
6 
+/* @TODO add 'no-zebra' table-style to the docs-base stylesheet */
7 
+/* Table without "zebra" striping */
8 
+.content-body table.no-zebra tr {
9 
+  background-color: transparent;
10 
+}
11 
+</style>
12 
+
5 13 
 # Where to chat or get help
6 14
7 
-There are several communications channels you can use to chat with Docker community members and developers.
15 
+There are several communications channels you can use to chat with Docker
16 
+community members and developers.
8 17
18 
+<!-- TODO (@thaJeztah) remove after docs/base is updated -->
9 19 
 <style type="text/css">
10 20 
 .tg  {border-collapse:collapse;border-spacing:0;text-align: left;}
11 
-.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;vertical-align:top;}
12 
-.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
21 
+.tg td{padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;vertical-align:top;}
22 
+.tg th{font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
13 23 
 </style>
14 24 
 <table class="tg">
15 25 
   <col width="25%">
16 26 
   <col width="75%">
17 27 
   <tr>
18 
-    <td class="tg-031e">Internet Relay Chat (IRC)</th>
19 
-    <td class="tg-031e"><p>IRC a direct line to our most knowledgeable Docker users. The <code>#docker</code> and <code>#docker-dev</code> group  on <strong>irc.freenode.net</strong>. IRC was first created in 1988. So, it is a rich chat protocol but it can overwhelm new users. You can search <a href="https://botbot.me/freenode/docker/#" target="_blank">our chat archives</a>.</p>
20 
-    Read our IRC quickstart guide below for an easy way to get started.</th>
28 
+    <td>Internet Relay Chat (IRC)</th>
29 
+    <td>
30 
+      <p>
31 
+        IRC a direct line to our most knowledgeable Docker users.
32 
+        The <code>#docker</code> and <code>#docker-dev</code> group on
33 
+        <strong>irc.freenode.net</strong>. IRC was first created in 1988.
34 
+        So, it is a rich chat protocol but it can overwhelm new users. You can search
35 
+        <a href="https://botbot.me/freenode/docker/#" target="_blank">our chat archives</a>.
36 
+      </p>
37 
+      Read our IRC quickstart guide below for an easy way to get started.
38 
+    </td>
21 39 
   </tr>
22 40 
   <tr>
23 
-    <td class="tg-031e">Google Groups</td>
24 
-    <td class="tg-031e">There are two groups. <a href="https://groups.google.com/forum/#!forum/docker-user" target="_blank">Docker-user</a> is for people using Docker containers. The <a href="https://groups.google.com/forum/#!forum/docker-dev" target="_blank">docker-dev</a> group is for contributors and other people contributing to the Docker project.</td>
41 
+    <td>Google Groups</td>
42 
+    <td>
43 
+      There are two groups.
44 
+      <a href="https://groups.google.com/forum/#!forum/docker-user" target="_blank">Docker-user</a>
45 
+      is for people using Docker containers.
46 
+      The <a href="https://groups.google.com/forum/#!forum/docker-dev" target="_blank">docker-dev</a>
47 
+      group is for contributors and other people contributing to the Docker
48 
+      project.
49 
+    </td>
25 50 
   </tr>
26 51 
   <tr>
27 
-    <td class="tg-031e">Twitter</td>
28 
-    <td class="tg-031e">You can follow <a href="https://twitter.com/docker/" target="_blank">Docker's twitter</a> to get updates on our products. You can also tweet us questions or just share blogs or stories.</td>
52 
+    <td>Twitter</td>
53 
+    <td>
54 
+      You can follow <a href="https://twitter.com/docker/" target="_blank">Docker's twitter</a>
55 
+      to get updates on our products. You can also tweet us questions or just
56 
+      share blogs or stories.
57 
+    </td>
29 58 
   </tr>
30 59 
   <tr>
31 
-    <td class="tg-031e">Stackoverflow</td>
32 
-    <td class="tg-031e">Stackoverflow has over 7000K Docker questions listed. We regularly monitor <a href="http://stackoverflow.com/search?tab=newest&q=docker" target="_blank">Docker questions</a> and so do many other knowledgeable Docker users.</td>
60 
+    <td>Stack Overflow</td>
61 
+    <td>
62 
+      Stack Overflow has over 7000K Docker questions listed. We regularly
63 
+      monitor <a href="http://stackoverflow.com/search?tab=newest&q=docker" target="_blank">Docker questions</a>
64 
+      and so do many other knowledgeable Docker users.
65 
+    </td>
33 66 
   </tr>
34 67 
 </table>
35 68
36 69
37 70 
 ## IRC Quickstart
38 71
39 
-IRC can also be overwhelming for new users. This quickstart shows you the easiest way to connect to IRC.
72 
+IRC can also be overwhelming for new users. This quickstart shows you
73 
+the easiest way to connect to IRC.
40 74
41 75 
 1. In your browser open <a href="http://webchat.freenode.net" target="_blank">http://webchat.freenode.net</a>
42 76
43 
-	![Login screen](/project/images/irc_connect.png)
77 
+    ![Login screen](/project/images/irc_connect.png)
44 78
45 79
46 80 
 2. Fill out the form.
47 81
48 
-	<style type="text/css">
49 
-.tg  {border-collapse:collapse;border-spacing:0;}
50 
-.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
51 
-.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
52 
-</style>
53 
-<table class="tg">
54 
-  <tr>
55 
-    <th class="tg-031e"><b>Nickname</b></th>
56 
-    <th class="tg-031e">The short name you want to be known as in IRC.</th>
57 
-  </tr>
58 
-  <tr>
59 
-    <td class="tg-031e"><b>Channels</b></td>
60 
-    <td class="tg-031e"><code>#docker</code></td>
61 
-  </tr>
62 
-  <tr>
63 
-    <td class="tg-031e"><b>reCAPTCHA</b></td>
64 
-    <td class="tg-031e">Use the value provided.</td>
65 
-  </tr>
66 
-</table>
82 
+    <!-- TODO (@thaJeztah) remove after docs/base is updated -->
83 
+    <style type="text/css">
84 
+    .tg   {border-collapse:collapse;border-spacing:0;}
85 
+    .tg td{padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
86 
+    .tg th{font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
87 
+    </style>
88 
+    <table class="tg no-zebra" style="width: auto">
89 
+      <tr>
90 
+        <td><b>Nickname</b></td>
91 
+        <td>The short name you want to be known as in IRC.</td>
92 
+      </tr>
93 
+      <tr>
94 
+        <td><b>Channels</b></td>
95 
+        <td><code>#docker</code></td>
96 
+      </tr>
97 
+      <tr>
98 
+        <td><b>reCAPTCHA</b></td>
99 
+        <td>Use the value provided.</td>
100 
+      </tr>
101 
+    </table>
67 102
68 103 
 3. Click "Connect".
69 104
70 
-	The system connects you to chat. You'll see a lot of text. At the bottom of
71 
-	the display is a command line. Just above the command line the system asks
72 
-	you to register.
73 
-
74 
-	![Login screen](/project/images/irc_after_login.png)
105 
+    The system connects you to chat. You'll see a lot of text. At the bottom of
106 
+    the display is a command line. Just above the command line the system asks
107 
+    you to register.
108 
+
109 
+    ![Login screen](/project/images/irc_after_login.png)
75 110
76 111
77 112 
 4. In the command line, register your nickname.
78 113
79 
-		/msg nickserv REGISTER password youremail@example.com
80 
-
81 
-	![Login screen](/project/images/register_nic.png)
82 
-
83 
-	The IRC system sends an email to the address you
84 
-	enter. The email contains instructions for completing your registration.
85 
-
114 
+        /msg NickServ REGISTER password youremail@example.com
115 
+
116 
+    ![Login screen](/project/images/register_nic.png)
117 
+
118 
+    The IRC system sends an email to the address you
119 
+    enter. The email contains instructions for completing your registration.
120 
+
86 121 
 5. Open your mail client and look for the email.
87 
-
88 
-	![Login screen](/project/images/register_email.png)
89 
-
122 
+
123 
+    ![Login screen](/project/images/register_email.png)
124 
+
90 125 
 6. Back in the browser, complete the registration according to the email.
91 126
92 
-	 	/msg NickServ VERIFY REGISTER moxiegirl_ acljtppywjnr
93 
-
127 
+        /msg NickServ VERIFY REGISTER moxiegirl_ acljtppywjnr
128 
+
94 129 
 7. Join the `#docker` group using the following command.
95 130
96 
-		/j #docker
97 
-
98 
-	You can also join the `#docker-dev` group.
99 
-
100 
-		/j #docker-dev
101 
-
131 
+        /j #docker
132 
+
133 
+    You can also join the `#docker-dev` group.
134 
+
135 
+        /j #docker-dev
136 
+
102 137 
 8. To ask questions to the channel just type messages in the command line.
103 138
104 139 
 	![Login screen](/project/images/irc_chat.png)
... ... 
@@ -108,12 +143,17 @@ IRC can also be overwhelming for new users. This quickstart shows you the easies
108 108
109 109 
 ### Tips and learning more about IRC
110 110
111 
-Next time you return to log into chat, you'll need to re-enter your password on the command line using this command:
111 
+Next time you return to log into chat, you'll need to re-enter your password
112 
+on the command line using this command:
113 
+
114 
+    /msg NickServ identify <password>
112 115
113 
-	/msg NickServ identify <password>
114 
-
115 116 
 If you forget or lose your password see <a
116 117 
 href="https://freenode.net/faq.shtml#sendpass" target="_blank">the FAQ on
117 118 
 freenode.net</a> to learn how to recover it.
118 
-
119 
-This quickstart was meant to get you up and into IRC very quickly. If you find IRC useful there is a lot more to learn. Drupal, another open source project, actually has <a href="https://www.drupal.org/irc/setting-up" target="_blank">written a lot of good documentation about using IRC</a> for their project (thanks Drupal!).
119 
+
120 
+This quickstart was meant to get you up and into IRC very quickly. If you find
121 
+IRC useful there is a lot more to learn. Drupal, another open source project,
122 
+actually has <a href="https://www.drupal.org/irc/setting-up" target="_blank">
123 
+written a lot of good documentation about using IRC</a> for their project
124 
+(thanks Drupal!).
docs/sources/project/images/gordon.jpeg
History View file @ efc625f
120 125 
Binary files a/docs/sources/project/images/gordon.jpeg and b/docs/sources/project/images/gordon.jpeg differ
docs/sources/project/make-a-contribution.md
History View file @ efc625f
... ... 
@@ -2,28 +2,78 @@ page_title: Make a project contribution
2 2 
 page_description: Basic workflow for Docker contributions
3 3 
 page_keywords: contribute, pull request, review, workflow, white-belt, black-belt, squash, commit
4 4
5 
+
6 
+<!-- TODO (@thaJeztah) remove after docs/base is updated -->
7 
+<style type="text/css">
8 
+.tg    {border-collapse:collapse;border-spacing:0;margin-bottom:15px;}
9 
+.tg td {background-color: #fff;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;vertical-align:top;}
10 
+.tg th {font-weight:bold;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;text-align:left;}
11 
+.tg .tg-e3zv{width:150px;}
12 
+</style>
13 
+
14 
+<style>
15 
+
16 
+/* GitHub label styles */
17 
+.gh-label {
18 
+    display: inline-block;
19 
+    padding: 3px 4px;
20 
+    font-size: 11px;
21 
+    font-weight: bold;
22 
+    line-height: 1;
23 
+    color: #fff;
24 
+    border-radius: 2px;
25 
+    box-shadow: inset 0 -1px 0 rgba(0,0,0,0.12);
26 
+}
27 
+
28 
+.gh-label.black-belt  { background-color: #000000; color: #ffffff; }
29 
+.gh-label.bug         { background-color: #fc2929; color: #ffffff; }
30 
+.gh-label.improvement { background-color: #bfe5bf; color: #2a332a; }
31 
+.gh-label.project-doc { background-color: #207de5; color: #ffffff; }
32 
+.gh-label.white-belt  { background-color: #ffffff; color: #333333; }
33 
+
34 
+</style>
35 
+
5 36 
 # Make a project contribution
6 37
7 
-Contributing is a process where you work with Docker maintainers and the community to improve Docker. There is a formal process for contributing. We try to keep our contribution process simple so you want to come back.
38 
+Contributing is a process where you work with Docker maintainers and the
39 
+community to improve Docker. There is a formal process for contributing.
40 
+We try to keep our contribution process simple so you want to come back.
8 41
9 42
10 
-In this section, you will create a new branch and work on some Docker code that you choose. Before you work through this process, take a few minutes to read through the next section which explains our basic contribution workflow.
43 
+In this section, you will create a new branch and work on some Docker code
44 
+that you choose. Before you work through this process, take a few minutes to
45 
+read through the next section which explains our basic contribution workflow.
11 46
12 47 
 ## The basic contribution workflow
13 48
14 
-You are about to work through our basic contribution workflow by fixing a single *white-belt* issue in the `docker/docker` repository. The workflow for fixing simple issues looks like this:
49 
+You are about to work through our basic contribution workflow by fixing a
50 
+single *white-belt* issue in the `docker/docker` repository. The workflow
51 
+for fixing simple issues looks like this:
15 52
16 53 
 ![Simple process](/project/images/existing_issue.png)
17 54
18 
-All Docker repositories have code and documentation. This workflow works for either content type. For example, you can find and fix doc or code issues. Also, you can propose a new Docker feature or propose a new Docker tutorial.
55 
+All Docker repositories have code and documentation. This workflow works
56 
+for either content type. For example, you can find and fix doc or code issues.
57 
+Also, you can propose a new Docker feature or propose a new Docker tutorial.
19 58
20 
-Some workflow stages have slight differences for code or documentation contributions. When you reach that point in the flow, we make sure to tell you.
59 
+Some workflow stages have slight differences for code or documentation
60 
+contributions. When you reach that point in the flow, we make sure to tell you.
21 61
22 62 
 ## Find and claim an existing issue
23 63
24 
-An existing issue is something reported by a Docker user. As issues come in, our maintainers triage them. Triage is its own topic. For now, it is important for you to know that triage includes ranking issues according to difficulty.
64 
+An existing issue is something reported by a Docker user. As issues come in,
65 
+our maintainers triage them. Triage is its own topic. For now, it is important
66 
+for you to know that triage includes ranking issues according to difficulty.
25 67
26 
-Triaged issues have either a **white-belt** or **black-belt** label.   A **white-belt** issue is considered an easier issue. Issues can have more than one the **white-belt** label, for example, **bug**, **improvement**, **/project/doc**, and so forth. These other labels are their for filtering purposes but you might also find them helpful.
68 
+Triaged issues have either a <strong class="gh-label white-belt">white-belt</strong>
69 
+or <strong class="gh-label black-belt">black-belt</strong> label.
70 
+A <strong class="gh-label white-belt">white-belt</strong> issue is considered
71 
+an easier issue. Issues can have more than one label, for example,
72 
+<strong class="gh-label bug">bug</strong>,
73 
+<strong class="gh-label improvement">improvement</strong>,
74 
+<strong class="gh-label project-doc">project/doc</strong>, and so forth.
75 
+These other labels are there for filtering purposes but you might also find
76 
+them helpful.
27 77
28 78 
 In the next procedure, you find and claim an open white-belt issue.
29 79
... ... 
@@ -33,44 +83,48 @@ In the next procedure, you find and claim an open white-belt issue.
33 33
34 34 
 2. Click on the "Issues" link.
35 35
36 
-   	A list of the open issues appears.
37 
-
38 
-	![Open issues](/project/images/issue_list.png)
36 
+    A list of the open issues appears.
37 
+
38 
+    ![Open issues](/project/images/issue_list.png)
39 39
40 
-3. Look for the **white-belt** items on the list.
40 
+3. Look for the <strong class="gh-label white-belt">white-belt</strong> items on the list.
41 41
42 
-4. Click on the "Labels" dropdown and select  **white-belt**.
42 
+4. Click on the "labels" dropdown and select  <strong class="gh-label white-belt">white-belt</strong>.
43 43
44 
-	The system filters to show only open **white-belt** issues.
44 
+    The system filters to show only open <strong class="gh-label white-belt">white-belt</strong> issues.
45 45
46 46 
 5. Open an issue that interests you.
47 47
48 
-	The comments on the issues can tell you both the problem and the potential
49 
-	solution.
50 
-
48 
+    The comments on the issues can tell you both the problem and the potential
49 
+    solution.
50 
+
51 51 
 6. Make sure that no other user has chosen to work on the issue.
52 52
53 53 
     We don't allow external contributors to assign issues to themselves, so you
54 54 
     need to read the comments to find if a user claimed an issue by saying:
55 55
56 
-    * "I'd love to give this a try~"
57 
-    * "I'll work on this!"
58 
-    * "I'll take this."
56 
+    - "I'd love to give this a try~"
57 
+    - "I'll work on this!"
58 
+    - "I'll take this."
59 59
60 60 
     The community is very good about claiming issues explicitly.
61 61
62 62 
 7. When you find an open issue that both interests you and is unclaimed, claim it yourself by adding a comment.
63 63
64 
-	![Easy issue](/project/images/easy_issue.png)
64 
+    ![Easy issue](/project/images/easy_issue.png)
65 
+
66 
+    This example uses issue 11038. Your issue # will be different depending on
67 
+    what you claimed.
65 68
66 
-	This example uses issue 11038. Your issue # will be different depending on
67 
-	what you claimed.
68 
-
69 69 
 8. Make a note of the issue number; you'll need it later.
70 70
71 71 
 ## Sync your fork and create a new branch
72 72
73 
-If you have followed along in this guide, you forked the `docker/docker` repository. Maybe that was an hour ago or a few days ago. In any case, before you start working on your issue, sync your repository with the upstream `docker/docker` master. Syncing ensures your repository has the latest changes.
73 
+If you have followed along in this guide, you forked the `docker/docker`
74 
+repository. Maybe that was an hour ago or a few days ago. In any case, before
75 
+you start working on your issue, sync your repository with the upstream
76 
+`docker/docker` master. Syncing ensures your repository has the latest
77 
+changes.
74 78
75 79 
 To sync your repository:
76 80
... ... 
@@ -78,315 +132,335 @@ To sync your repository:
78 78
79 79 
 2. Change directory to the `docker-fork` root.
80 80
81 
-		$ cd ~/repos/docker-fork
81 
+        $ cd ~/repos/docker-fork
82 82
83 83 
 3. Checkout the master branch.
84 84
85 
-		$ git checkout master
86 
-		Switched to branch 'master'
87 
-		Your branch is up-to-date with 'origin/master'.
88 
-
89 
-	Recall that `origin/master` is a branch on your remote GitHub repository.
85 
+        $ git checkout master
86 
+        Switched to branch 'master'
87 
+        Your branch is up-to-date with 'origin/master'.
88 
+
89 
+    Recall that `origin/master` is a branch on your remote GitHub repository.
90 90
91 91 
 4. Make sure you have the upstream remote `docker/docker` by listing them.
92 92
93 
-		$ git remote -v
94 
-		origin	https://github.com/moxiegirl/docker.git (fetch)
95 
-		origin	https://github.com/moxiegirl/docker.git (push)
96 
-		upstream	https://github.com/docker/docker.git (fetch)
97 
-		upstream	https://github.com/docker/docker.git (
98 
-
99 
-	If the `upstream` is missing, add it.
100 
-
101 
-		$ git remote add upstream https://github.com/docker/docker.git
93 
+        $ git remote -v
94 
+        origin	https://github.com/moxiegirl/docker.git (fetch)
95 
+        origin	https://github.com/moxiegirl/docker.git (push)
96 
+        upstream	https://github.com/docker/docker.git (fetch)
97 
+        upstream	https://github.com/docker/docker.git (
98 
+
99 
+    If the `upstream` is missing, add it.
100 
+
101 
+        $ git remote add upstream https://github.com/docker/docker.git
102 102
103 103 
 5. Fetch all the changes from the `upstream/master` branch.
104 104
105 
-		$ git fetch upstream/master
106 
-		remote: Counting objects: 141, done.
107 
-		remote: Compressing objects: 100% (29/29), done.
108 
-		remote: Total 141 (delta 52), reused 46 (delta 46), pack-reused 66
109 
-		Receiving objects: 100% (141/141), 112.43 KiB | 0 bytes/s, done.
110 
-		Resolving deltas: 100% (79/79), done.
111 
-		From github.com:docker/docker
112 
-		   9ffdf1e..01d09e4  docs       -> upstream/docs
113 
-		   05ba127..ac2521b  master     -> upstream/master
114 
-
115 
-	This command says get all the changes from the `master` branch belonging to
116 
-	the `upstream` remote.
117 
-
105 
+        $ git fetch upstream/master
106 
+        remote: Counting objects: 141, done.
107 
+        remote: Compressing objects: 100% (29/29), done.
108 
+        remote: Total 141 (delta 52), reused 46 (delta 46), pack-reused 66
109 
+        Receiving objects: 100% (141/141), 112.43 KiB | 0 bytes/s, done.
110 
+        Resolving deltas: 100% (79/79), done.
111 
+        From github.com:docker/docker
112 
+           9ffdf1e..01d09e4  docs       -> upstream/docs
113 
+           05ba127..ac2521b  master     -> upstream/master
114 
+
115 
+    This command says get all the changes from the `master` branch belonging to
116 
+    the `upstream` remote.
117 
+
118 118 
 7. Rebase your local master with the `upstream/master`.
119 119
120 
-		$ git rebase upstream/master
121 
-		First, rewinding head to replay your work on top of it...
122 
-		Fast-forwarded master to upstream/master.
123 
-
124 
-	This command writes all the commits from the upstream branch into your local
125 
-	branch.
126 
-
120 
+        $ git rebase upstream/master
121 
+        First, rewinding head to replay your work on top of it...
122 
+        Fast-forwarded master to upstream/master.
123 
+
124 
+    This command writes all the commits from the upstream branch into your local
125 
+    branch.
126 
+
127 127 
 8.  Check the status of your local branch.
128 128
129 
-		$ git status
130 
-		On branch master
131 
-		Your branch is ahead of 'origin/master' by 38 commits.
132 
-		  (use "git push" to publish your local commits)
133 
-		nothing to commit, working directory clean
129 
+        $ git status
130 
+        On branch master
131 
+        Your branch is ahead of 'origin/master' by 38 commits.
132 
+          (use "git push" to publish your local commits)
133 
+        nothing to commit, working directory clean
134 134
135 
-	Your local repository now has any changes from the `upstream` remote.  You
136 
-	need to push the changes to your own remote fork which is `origin/master`.
135 
+    Your local repository now has any changes from the `upstream` remote.  You
136 
+    need to push the changes to your own remote fork which is `origin/master`.
137 137
138 138 
 9. Push the rebased master to `origin/master`.
139 139
140 
-		$ git push
141 
-		Username for 'https://github.com': moxiegirl
142 
-		Password for 'https://moxiegirl@github.com':
143 
-		Counting objects: 223, done.
144 
-		Compressing objects: 100% (38/38), done.
145 
-		Writing objects: 100% (69/69), 8.76 KiB | 0 bytes/s, done.
146 
-		Total 69 (delta 53), reused 47 (delta 31)
147 
-		To https://github.com/moxiegirl/docker.git
148 
-		   8e107a9..5035fa1  master -> master
149 
-
150 
-	If you check
140 
+        $ git push
141 
+        Username for 'https://github.com': moxiegirl
142 
+        Password for 'https://moxiegirl@github.com':
143 
+        Counting objects: 223, done.
144 
+        Compressing objects: 100% (38/38), done.
145 
+        Writing objects: 100% (69/69), 8.76 KiB | 0 bytes/s, done.
146 
+        Total 69 (delta 53), reused 47 (delta 31)
147 
+        To https://github.com/moxiegirl/docker.git
148 
+           8e107a9..5035fa1  master -> master
151 149
152 150 
 9. Create a new feature branch to work on your issue.
153 151
154 
-	Your branch name should have the format `XXXX-descriptive` where `XXXX` is
155 
-	the issue number you are working on. For example:
152 
+    Your branch name should have the format `XXXX-descriptive` where `XXXX` is
153 
+    the issue number you are working on. For example:
156 154
157 
-		$ git checkout -b 11038-fix-rhel-link
158 
-		Switched to a new branch '11038-fix-rhel-link'
159 
-
160 
-	Your branch should be up-to-date with the upstream/master. Why? Because you
161 
-	branched off a freshly synced master.  Let's check this anyway in the next
162 
-	step.
155 
+        $ git checkout -b 11038-fix-rhel-link
156 
+        Switched to a new branch '11038-fix-rhel-link'
157 
+
158 
+    Your branch should be up-to-date with the upstream/master. Why? Because you
159 
+    branched off a freshly synced master.  Let's check this anyway in the next
160 
+    step.
163 161
164 162 
 9. Rebase your branch from upstream/master.
165 163
166 
-		$ git rebase upstream/master
167 
-		Current branch 11038-fix-rhel-link is up to date.
168 
-
169 
-	At this point, your local branch, your remote repository, and the Docker
170 
-	repository all have identical code. You are ready to make changesfor your
171 
-	issues.
172 
-
164 
+        $ git rebase upstream/master
165 
+        Current branch 11038-fix-rhel-link is up to date.
166 
+
167 
+    At this point, your local branch, your remote repository, and the Docker
168 
+    repository all have identical code. You are ready to make changesfor your
169 
+    issues.
170 
+
173 171 
 ## Work on your issue
174 172
175 
-The work you do for your issue depends on the specific issue you picked. This section gives you a step-by-step workflow. Where appropriate, it provides command examples. However, this is a generalized workflow, depending on your issue you may you may repeat steps or even skip some. How much time it takes you depends on you --- you could spend days or 30 minutes of your time.
173 
+The work you do for your issue depends on the specific issue you picked.
174 
+This section gives you a step-by-step workflow. Where appropriate, it provides
175 
+command examples. However, this is a generalized workflow, depending on your
176 
+issue you may you may repeat steps or even skip some. How much time it takes
177 
+you depends on you --- you could spend days or 30 minutes of your time.
176 178
177 179 
 Follow this workflow as you work:
178 180
179 181 
 1. Review the appropriate style guide.
180 182
181 
-	If you are changing code, review the <a href="../coding-style"
182 
-	target="_blank">coding style guide</a>. Changing documentation? Review the
183 
-	<a href="../doc-style" target="_blank">documentation style guide</a>.
183 
+    If you are changing code, review the <a href="../coding-style"
184 
+    target="_blank">coding style guide</a>. Changing documentation? Review the
185 
+    <a href="../doc-style" target="_blank">documentation style guide</a>.
184 186
185 187 
 2. Make changes in your feature branch.
186 188
187 
-	Your feature branch you created in the last section. Here you use the
188 
-	development container. If you are making a code change, you can mount your
189 
-	source into a development container and iterate that way. For documentation
190 
-	alone, you can work on your local host.
191 
-
192 
-	Review <a href="../set-up-dev-env" target="_blank">if you forgot the details
193 
-	of working with a container</a>.
189 
+    Your feature branch you created in the last section. Here you use the
190 
+    development container. If you are making a code change, you can mount your
191 
+    source into a development container and iterate that way. For documentation
192 
+    alone, you can work on your local host.
193 
+
194 
+    Review <a href="../set-up-dev-env" target="_blank">if you forgot the details
195 
+    of working with a container</a>.
194 196
195 197
196 198 
 3. Test your changes as you work.
197 199
198 
-	If you have followed along with the guide, you know the `make test` target
199 
-	runs the entire test suite and `make docs` builds the documentation. If you
200 
-	forgot the other test targets, see the documentation for <a
201 
-	href="../test-and-docs" target="_blank">testing both code and
202 
-	documentation</a>.
200 
+    If you have followed along with the guide, you know the `make test` target
201 
+    runs the entire test suite and `make docs` builds the documentation. If you
202 
+    forgot the other test targets, see the documentation for <a
203 
+    href="../test-and-docs" target="_blank">testing both code and
204 
+    documentation</a>.
203 205
204 206 
 4. For code changes, add unit tests if appropriate.
205 207
206 
-	If you add new functionality or change existing functionality, you should
207 
-	add a unit test also. Use the existing test files for inspiration. Aren't
208 
-	sure if you need tests? Skip this step; you can add them later in the
209 
-	process if necessary.
208 
+    If you add new functionality or change existing functionality, you should
209 
+    add a unit test also. Use the existing test files for inspiration. Aren't
210 
+    sure if you need tests? Skip this step; you can add them later in the
211 
+    process if necessary.
210 212
211 213 
 5. Format your source files correctly.
212 214
213 
-	<style type="text/css">
214 
-	.tg  {border-collapse:collapse;border-spacing:0;margin-bottom:15px;}
215 
-	.tg td{font-family:Arial, sans-serif;font-size:14px;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;vertical-align:top;}
216 
-	.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:bold;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;text-align:left;}
217 
-	.tg .tg-e3zv{width:150px;}
218 
-	</style>
219 
-	<table class="tg">
220 
-	  <tr>
221 
-		<th class="tg-e3zv">File type</th>
222 
-		<th class="tg-031e">How to format</th>
223 
-	  </tr>
224 
-	  <tr>
225 
-		<td class="tg-e3zv"><code>.go</code></td>
226 
-		<td class="tg-031e"><p>Format <code>.go</code> files using the <code>gofmt</code> command. For example, if you edited the `docker.go` file you would format the file
227 
-		like this:
228 
-		</p>
229 
-		<p><code>$ gofmt -s -w file.go</code></p>
230 
-		<p>
231 
-		Most file editors have a plugin to format for you. Check your editor's
232 
-		documentation.
233 
-		</p>
234 
-		</td>
235 
-	  </tr>
236 
-	  <tr>
237 
-		<td class="tg-e3zv"><code>.md</code> and non-<code>.go</code> files</td>
238 
-		<td class="tg-031e">Wrap lines to 80 characters.</td>
239 
-	  </tr>
240 
-	</table>
241 
-
215 
+    <table class="tg">
216 
+      <thead>
217 
+      <tr>
218 
+        <th class="tg-e3zv">File type</th>
219 
+        <th>How to format</th>
220 
+      </tr>
221 
+      </thead>
222 
+      <tbody>
223 
+      <tr>
224 
+        <td class="tg-e3zv"><code>.go</code></td>
225 
+        <td>
226 
+            <p>
227 
+            Format <code>.go</code> files using the <code>gofmt</code> command.
228 
+            For example, if you edited the `docker.go` file you would format the file
229 
+        like this:
230 
+        </p>
231 
+        <p><code>$ gofmt -s -w file.go</code></p>
232 
+        <p>
233 
+        Most file editors have a plugin to format for you. Check your editor's
234 
+        documentation.
235 
+        </p>
236 
+        </td>
237 
+      </tr>
238 
+      <tr>
239 
+        <td  class="tg-e3zv" style="white-space: nowrap"><code>.md</code> and non-<code>.go</code> files</td>
240 
+        <td>Wrap lines to 80 characters.</td>
241 
+      </tr>
242 
+      </tbody>
243 
+    </table>
242 244
243 245 
 6. List your changes.
244 246
245 
-		$ git status
246 
-		On branch 11038-fix-rhel-link
247 
-		Changes not staged for commit:
248 
-		  (use "git add <file>..." to update what will be committed)
249 
-		  (use "git checkout -- <file>..." to discard changes in working directory)
250 
-
251 
-			modified:   docs/sources/installation/mac.md
252 
-			modified:   docs/sources/installation/rhel.md
253 
-
254 
-	The `status` command lists what changed in the repository. Make sure you see
255 
-	the changes you expect.
256 
-
247 
+        $ git status
248 
+        On branch 11038-fix-rhel-link
249 
+        Changes not staged for commit:
250 
+          (use "git add <file>..." to update what will be committed)
251 
+          (use "git checkout -- <file>..." to discard changes in working directory)
252 
+
253 
+        modified:   docs/sources/installation/mac.md
254 
+        modified:   docs/sources/installation/rhel.md
255 
+
256 
+    The `status` command lists what changed in the repository. Make sure you see
257 
+    the changes you expect.
258 
+
257 259 
 7. Add your change to Git.
258 260
259 
-		$ git add docs/sources/installation/mac.md
260 
-		$ git add docs/sources/installation/rhel.md
261 
-
262 
-
261 
+        $ git add docs/sources/installation/mac.md
262 
+        $ git add docs/sources/installation/rhel.md
263 
+
264 
+
263 265 
 8. Commit your changes making sure you use the `-s` flag to sign your work.
264 266
265 
-		$ git commit -s -m "Fixing RHEL link"
266 
-
267 
+        $ git commit -s -m "Fixing RHEL link"
268 
+
267 269 
 9. Push your change to your repository.
268 
-
269 
-		$ git push --set-upstream origin 11038-fix-rhel-link
270 
-		Username for 'https://github.com': moxiegirl
271 
-		Password for 'https://moxiegirl@github.com':
272 
-		Counting objects: 60, done.
273 
-		Compressing objects: 100% (7/7), done.
274 
-		Writing objects: 100% (7/7), 582 bytes | 0 bytes/s, done.
275 
-		Total 7 (delta 6), reused 0 (delta 0)
276 
-		To https://github.com/moxiegirl/docker.git
277 
-		 * [new branch]      11038-fix-rhel-link -> 11038-fix-rhel-link
278 
-		Branch 11038-fix-rhel-link set up to track remote branch 11038-fix-rhel-link from origin.
279 
-
270 
+
271 
+        $ git push --set-upstream origin 11038-fix-rhel-link
272 
+        Username for 'https://github.com': moxiegirl
273 
+        Password for 'https://moxiegirl@github.com':
274 
+        Counting objects: 60, done.
275 
+        Compressing objects: 100% (7/7), done.
276 
+        Writing objects: 100% (7/7), 582 bytes | 0 bytes/s, done.
277 
+        Total 7 (delta 6), reused 0 (delta 0)
278 
+        To https://github.com/moxiegirl/docker.git
279 
+         * [new branch]      11038-fix-rhel-link -> 11038-fix-rhel-link
280 
+        Branch 11038-fix-rhel-link set up to track remote branch 11038-fix-rhel-link from origin.
281 
+
280 282 
 10. Open your fork on GitHub to see your change.
281 283
282 284 
 ## Create a pull request to docker/docker
283 285
284 
-A pull request sends your code to the Docker maintainers for review. Your pull request goes from your forked repository to the `docker/docker` repository.  You can see <a href="https://github.com/docker/docker/pulls" target="_blank">the list of active pull requests to Docker</a> on GitHub.
286 
+A pull request sends your code to the Docker maintainers for review. Your pull
287 
+request goes from your forked repository to the `docker/docker` repository.
288 
+You can see <a href="https://github.com/docker/docker/pulls" target="_blank">the
289 
+list of active pull requests to Docker</a>
290 
+on GitHub.
285 291
286 292 
 To create a pull request for your change:
287 293
288 294 
 1. In a terminal window, go to the root of your `docker-fork` repository.
289 295
290 
-		$ cd ~/repos/docker-fork
296 
+        $ cd ~/repos/docker-fork
291 297
292 298 
 2. Checkout your feature branch.
293 299
294 
-		$ git checkout 11038-fix-rhel-link
295 
-		Already on '11038-fix-rhel-link'
300 
+        $ git checkout 11038-fix-rhel-link
301 
+        Already on '11038-fix-rhel-link'
296 302
297 303 
 3. Run the full test suite on your branch.
298 304
299 
-		$ make test
300 
-
301 
-	All the tests should pass. If they don't, find out why and correct the
302 
-	situation. If you also modified the documentation,  run `make docs` and
303 
-	check your work.
304 
-
305 
+        $ make test
306 
+
307 
+    All the tests should pass. If they don't, find out why and correct the
308 
+    situation. If you also modified the documentation,  run `make docs` and
309 
+    check your work.
310 
+
305 311 
 4.  Update your remote repository with any changes that result from your last minute checks.
306 312
307 
-	Use the `git add`, the `git commit -s`, and `git push` commands to do this.
308 
-
313 
+    Use the `git add`, the `git commit -s`, and `git push` commands to do this.
314 
+
309 315 
 4. Fetch any of the last minute changes from `docker/docker`.
310 316
311 
-		$ git fetch upstream master
312 
-		From github.com:docker/docker
313 
-		 * branch            master     -> FETCH_HEAD
317 
+        $ git fetch upstream master
318 
+        From github.com:docker/docker
319 
+         * branch            master     -> FETCH_HEAD
314 320
315 321 
 5. Squash your individual separate commits into one by using Git’s interactive rebase:
316 322
317 
-		$ git rebase -i upstream/master
318 
-
319 
-	This commit will open up your favorite editor with all the comments from
320 
-	all your latest commits.
321 
-
322 
-		pick 1a79f55 Tweak some of the other text for grammar
323 
-		pick 53e4983 Fix a link
324 
-		pick 3ce07bb Add a new line about RHEL
325 
-
323 
+        $ git rebase -i upstream/master
324 
+
325 
+    This commit will open up your favorite editor with all the comments from
326 
+    all your latest commits.
327 
+
328 
+        pick 1a79f55 Tweak some of the other text for grammar
329 
+        pick 53e4983 Fix a link
330 
+        pick 3ce07bb Add a new line about RHEL
331 
+
326 332 
 6. Replace the `pick` keyword with `squash` on all but the first commit.
327 
-
328 
-		pick 1a79f55 Tweak some of the other text for grammar
329 
-		squash 53e4983 Fix a link
330 
-		squash 3ce07bb Add a new line about RHEL
331 
-
332 
-	After closing the file, `git` opens your editor again to edit the commit
333 
-	message.
334 
-
333 
+
334 
+        pick 1a79f55 Tweak some of the other text for grammar
335 
+        squash 53e4983 Fix a link
336 
+        squash 3ce07bb Add a new line about RHEL
337 
+
338 
+    After closing the file, `git` opens your editor again to edit the commit
339 
+    message.
340 
+
335 341 
 7. Save your commit message.
336 342
337 343
338 344 
 8. Push any changes to your fork on GitHub.
339 345
340 
-		$ git push origin 11038-fix-rhel-link
341 
-
346 
+        $ git push origin 11038-fix-rhel-link
347 
+
342 348 
 9. Open your browser to your fork on GitHub.
343 349
344 
-	You should see the latest activity from your branch.
345 
-
346 
-	![Latest commits](/project/images/latest_commits.png)
350 
+    You should see the latest activity from your branch.
351 
+
352 
+    ![Latest commits](/project/images/latest_commits.png)
353 
+
347 354
348 
-
349 355 
 10. Click "Compare & pull request".
350 356
351 
-	The system displays the pull request dialog.
352 
-
353 
-	![PR dialog](/project/images/to_from_pr.png)
354 
-
355 
-	The pull request compares your changes to the `master` branch on the `docker/docker` repository.
357 
+    The system displays the pull request dialog.
358 
+
359 
+    ![PR dialog](/project/images/to_from_pr.png)
360 
+
361 
+    The pull request compares your changes to the `master` branch on the
362 
+    `docker/docker` repository.
356 363
357 364 
 11. Edit the dialog's description and add a reference to the issue you are fixing.
358 365
359 
-	GitHub helps you out by searching for the issue as you type.
360 
-
361 
-	![Fixes issue](/project/images/fixes_num.png)
366 
+    GitHub helps you out by searching for the issue as you type.
367 
+
368 
+    ![Fixes issue](/project/images/fixes_num.png)
362 369
363 370 
 12. Scroll down and verify the PR contains the commits and changes you expect.
364 371
365 
-	For example, is the file count correct? Are the changes in the files what
366 
-	you expect.
367 
-
368 
-	![Commits](/project/images/commits_expected.png)
372 
+    For example, is the file count correct? Are the changes in the files what
373 
+    you expect.
374 
+
375 
+    ![Commits](/project/images/commits_expected.png)
369 376
370 377 
 13. Press "Create pull request".
371 378
372 
-	The system creates the request and opens it for you in the `docker/docker`
373 
-	repository.
379 
+    The system creates the request and opens it for you in the `docker/docker`
380 
+    repository.
374 381
375 
-	![Pull request made](/project/images/pull_request_made.png)
382 
+    ![Pull request made](/project/images/pull_request_made.png)
376 383
377 384 
 ## Your pull request under review
378 385
379 
-At this point, your pull request is reviewed. The first reviewer is Gordon. He might who might look slow in this picture:
386 
+At this point, your pull request is reviewed. The first reviewer is Gordon.
387 
+He might who might look slow in this picture:
380 388
381 389 
 ![Gordon](/project/images/gordon.jpeg)
382 390
383 
-He is actually pretty fast over a network. He checks your pull request (PR) for common problems like missing signatures. If Gordon finds a problem, he'll send  an email to your GitHub user.
391 
+He is actually pretty fast over a network. He checks your pull request (PR)
392 
+for common problems like missing signatures. If Gordon finds a problem, he'll
393 
+send  an email to your GitHub user.
384 394
385 
-After Gordon, the core Docker maintainers look at your pull request and comment on it. The shortest comment you might see is `LGTM` which means **l**ooks-**g**ood-**t**o-**m**e. If you get an `LGTM`, that is a good thing, you passed that review.
395 
+After Gordon, the core Docker maintainers look at your pull request and comment
396 
+on it. The shortest comment you might see is `LGTM` which means
397 
+**l**ooks-**g**ood-**t**o-**m**e. If you get an `LGTM`, that is a good thing,
398 
+you passed that review.
386 399
387 
-For complex changes, maintainers may ask you questions or ask you to change something about your submission. All maintainer comments on a PR go to the email address associated with your GitHub account. Any GitHub user who "participates" in a PR receives an email to.  Participating means creating or commenting on a PR.
400 
+For complex changes, maintainers may ask you questions or ask you to change
401 
+something about your submission. All maintainer comments on a PR go to the
402 
+email address associated with your GitHub account. Any GitHub user who
403 
+"participates" in a PR receives an email to. Participating means creating or
404 
+commenting on a PR.
388 405
389 
-Our maintainers are very experienced Docker users and open source contributors. So, they value your time and will try to work efficiently with you by keeping their comments specific and brief.  If they ask you to make a change, you'll need to update your pull request with additional changes.
406 
+Our maintainers are very experienced Docker users and open source contributors.
407 
+So, they value your time and will try to work efficiently with you by keeping
408 
+their comments specific and brief. If they ask you to make a change, you'll
409 
+need to update your pull request with additional changes.
390 410
391 411 
 To update your existing pull request:
392 412
... ... 
@@ -394,44 +468,50 @@ To update your existing pull request:
394 394
395 395 
 2. Commit the change with the `git commit --amend` command.
396 396
397 
-		$ git commit --amend
398 
-
399 
-	Git opens an editor containing your last commit message.
400 
-
397 
+    	$ git commit --amend
398 
+
399 
+    Git opens an editor containing your last commit message.
400 
+
401 401 
 3. Adjust your last comment to reflect this new change.
402 402
403 
-		Added a new sentence per Anaud's suggestion
403 
+        Added a new sentence per Anaud's suggestion
404 404
405 
-		Signed-off-by: Mary Anthony <mary@docker.com>
405 
+        Signed-off-by: Mary Anthony <mary@docker.com>
406 406
407 
-		# Please enter the commit message for your changes. Lines starting
408 
-		# with '#' will be ignored, and an empty message aborts the commit.
409 
-		# On branch 11038-fix-rhel-link
410 
-		# Your branch is up-to-date with 'origin/11038-fix-rhel-link'.
411 
-		#
412 
-		# Changes to be committed:
413 
-		#		modified:   docs/sources/installation/mac.md
414 
-		#		modified:   docs/sources/installation/rhel.md
407 
+        # Please enter the commit message for your changes. Lines starting
408 
+        # with '#' will be ignored, and an empty message aborts the commit.
409 
+        # On branch 11038-fix-rhel-link
410 
+        # Your branch is up-to-date with 'origin/11038-fix-rhel-link'.
411 
+        #
412 
+        # Changes to be committed:
413 
+        #		modified:   docs/sources/installation/mac.md
414 
+        #		modified:   docs/sources/installation/rhel.md
415 415
416 416 
 4. Push to your origin.
417 417
418 
-		$ git push origin
419 
-
418 
+        $ git push origin
419 
+
420 420 
 5. Open your browser to your pull request on GitHub.
421 421
422 
-	You should see your pull request now contains your newly pushed code.
422 
+    You should see your pull request now contains your newly pushed code.
423 423
424 424 
 6. Add a comment to your pull request.
425 
-
426 
-	GitHub only notifies PR participants when you comment. For example, you can
427 
-	mention that you updated your PR. Your comment alerts the maintainers that
428 
-	you made an update.
429 
-
430 
-A change requires LGTMs from an absolute majority of an affected component's maintainers. For example, if you change `docs/` and `registry/` code, an absolute majority of the `docs/` and the `registry/` maintainers must approve your PR. Once you get approval, we merge your pull request into Docker's `master` cod branch.
425 
+
426 
+    GitHub only notifies PR participants when you comment. For example, you can
427 
+    mention that you updated your PR. Your comment alerts the maintainers that
428 
+    you made an update.
429 
+
430 
+A change requires LGTMs from an absolute majority of an affected component's
431 
+maintainers. For example, if you change `docs/` and `registry/` code, an
432 
+absolute majority of the `docs/` and the `registry/` maintainers must approve
433 
+your PR. Once you get approval, we merge your pull request into Docker's
434 
+`master` code branch.
431 435
432 436 
 ## After the merge
433 437
434 
-It can take time to see a merged pull request in Docker's official release. A master build is available almost immediately though. Docker builds and updates its development binaries after each merge to `master`.
438 
+It can take time to see a merged pull request in Docker's official release.
439 
+A master build is available almost immediately though. Docker builds and
440 
+updates its development binaries after each merge to `master`.
435 441
436 442 
 1. Browse to <a href="https://master.dockerproject.com/" target="_blank">https://master.dockerproject.com/</a>.
437 443
... ... 
@@ -439,15 +519,22 @@ It can take time to see a merged pull request in Docker's official release. A ma
439 439
440 440 
 3. Download and run the binary.
441 441
442 
-	You might want to run the binary in a container though. This
443 
-	will keep your local host environment clean.
442 
+    You might want to run the binary in a container though. This
443 
+    will keep your local host environment clean.
444 444
445 445 
 4. View any documentation changes at <a href="http://docs.master.dockerproject.com/" target="_blank">docs.master.dockerproject.com</a>.
446 446
447 
-Once you've verified everything merged, feel free to delete your feature branch from your fork. For information on how to do this, <a href="https://help.github.com/articles/deleting-unused-branches/" target="_blank">see the GitHub help on deleting branches</a>.
447 
+Once you've verified everything merged, feel free to delete your feature branch
448 
+from your fork. For information on how to do this,
449 
+<a href="https://help.github.com/articles/deleting-unused-branches/" target="_blank">
450 
+see the GitHub help on deleting branches</a>.
448 451
449 452 
 ## Where to go next
450 453
451 
-At this point, you have completed all the basic tasks in our contributors guide. If you enjoyed contributing, let us know by completing another **white-belt** issue or two. We really appreciate the help.
454 
+At this point, you have completed all the basic tasks in our contributors guide.
455 
+If you enjoyed contributing, let us know by completing another
456 
+<strong class="gh-label white-belt">white-belt</strong>
457 
+issue or two. We really appreciate the help.
452 458
453 
-If you are very experienced and want to make a major change, go onto [learn about advanced contributing](/project/advanced-contributing).
454 459 
\ No newline at end of file
460 
+If you are very experienced and want to make a major change, go onto
461 
+[learn about advanced contributing](/project/advanced-contributing).
docs/sources/project/set-up-dev-env.md
History View file @ efc625f
... ... 
@@ -2,6 +2,14 @@ page_title: Work with a development container
2 2 
 page_description: How to use Docker's development environment
3 3 
 page_keywords: development, inception, container, image Dockerfile, dependencies, Go, artifacts
4 4
5 
+
6 
+<!-- TODO (@thaJeztah) remove after docs/base is updated -->
7 
+<style type="text/css">
8 
+.tg   {border-collapse:collapse;border-spacing:0;}
9 
+.tg td{font-family:monospace, serif;font-size:11px;padding:10px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
10 
+.tg th{font-family:monospace, sans-serif;font-size:11px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
11 
+</style>
12 
+
5 13 
 # Work with a development container
6 14
7 15 
 In this section, you learn to develop like a member of Docker's core team.
... ... 
@@ -11,178 +19,176 @@ dependencies: system libraries and binaries, go environment, go dependencies,
11 11 
 etc.
12 12
13 13 
 Docker's development environment is itself, ultimately a Docker container.
14 
-You use the `docker` repository and its `Dockerfile` to create a Docker image, run a Docker container, and develop code in the container. Docker itself builds, tests, and releases new Docker versions using this container.
15 
-
16 
-If you followed the procedures that <a href="../set-up-prereqs" target="_blank">set up the prerequisites</a>, you should have a fork of the
17 
-`docker/docker` repository. You also created a branch called `dry-run-test`. In this section, you continue working with your fork on this branch.
14 
+You use the `docker` repository and its `Dockerfile` to create a Docker image,
15 
+run a Docker container, and develop code in the container. Docker itself builds,
16 
+tests, and releases new Docker versions using this container.
18 17
18 
+If you followed the procedures that <a href="../set-up-prereqs" target="_blank">
19 
+set up the prerequisites</a>, you should have a fork of the `docker/docker`
20 
+repository. You also created a branch called `dry-run-test`. In this section,
21 
+you continue working with your fork on this branch.
19 22
20 23 
 ##  Clean your host of Docker artifacts
21 24
22 
-Docker developers run the latest stable release of the Docker software; Or Boot2docker and Docker if their machine is Mac OS X. They clean their local hosts of unnecessary Docker artifacts such as stopped containers or unused images. Cleaning unnecessary artifacts isn't strictly necessary but it is good practice, so it is included here.
25 
+Docker developers run the latest stable release of the Docker software; Or
26 
+Boot2docker and Docker if their machine is Mac OS X. They clean their local
27 
+hosts of unnecessary Docker artifacts such as stopped containers or unused
28 
+images. Cleaning unnecessary artifacts isn't strictly necessary but it is
29 
+good practice, so it is included here.
23 30
24 31 
 To remove unnecessary artifacts.
25 32
26 33 
 1. Verify that you have no unnecessary containers running on your host.
27 34
28 
-		$ docker ps
29 
-
30 
-	You should see something similar to the following:
31 
-
32 
-	<style type="text/css">
33 
-	.tg  {border-collapse:collapse;border-spacing:0;} .tg td{font-family:monospace, serif;font-size:11px;padding:10px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;} .tg th{font-family:monospace, sans-serif;font-size:11px;font-weight:normal;padding:10px
34 
-5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
35 
-	</style>
36 
-	<table class="tg">
37 
-	  <tr>
38 
-		<th class="tg-031e">CONTAINER ID</th>
39 
-		<th class="tg-031e">IMAGE</th>
40 
-		<th class="tg-031e">COMMAND</th>
41 
-		<th class="tg-031e">CREATED</th>
42 
-		<th class="tg-031e">STATUS</th>
43 
-		<th class="tg-031e">PORTS</th>
44 
-		<th class="tg-031e">NAMES</th>
45 
-	  </tr>
46 
-	</table>
47 
-
48 
-	There are no running containers on this host. If you have running but unused
49 
-	containers, stop and then remove them with the `docker stop` and `docker rm`
50 
-	commands.
35 
+        $ docker ps
36 
+
37 
+    You should see something similar to the following:
38 
+
39 
+    <table class="tg code">
40 
+      <tr>
41 
+        <th>CONTAINER ID</th>
42 
+        <th>IMAGE</th>
43 
+        <th>COMMAND</th>
44 
+        <th>CREATED</th>
45 
+        <th>STATUS</th>
46 
+        <th>PORTS</th>
47 
+        <th>NAMES</th>
48 
+      </tr>
49 
+    </table>
50 
+
51 
+    There are no running containers on this host. If you have running but unused
52 
+    containers, stop and then remove them with the `docker stop` and `docker rm`
53 
+    commands.
51 54
52 55 
 2. Verify that your host has no dangling images.
53 56
54 
-		$ docker images
55 
-
56 
-	You should see something similar to the following:
57 
-
58 
-	<style type="text/css">
59 
-	.tg  {border-collapse:collapse;border-spacing:0;} .tg td{font-family:monospace, serif;font-size:11px;padding:10px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;} .tg th{font-family:monospace, serif;font-size:11px;font-weight:normal;padding:10px
60 
-5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
61 
-	</style>
62 
-	<table class="tg">
63 
-	  <tr>
64 
-		<th class="tg-031e">REPOSITORY</th>
65 
-		<th class="tg-031e">TAG</th>
66 
-		<th class="tg-031e">IMAGE ID</th>
67 
-		<th class="tg-031e">CREATED</th>
68 
-		<th class="tg-031e">VIRTUAL SIZE</th>
69 
-	  </tr>
70 
-	</table>
71 
-
72 
-	This host has no images. You may have one or more _dangling_ images. A
73 
-	dangling image is not used by a running container and is not an ancestor of
74 
-	another image on your system. A fast way to remove dangling containers is
75 
-	the following:
76 
-
77 
-		$ docker rmi -f $(docker images -q -a -f dangling=true)
78 
-
79 
-	This command uses `docker images` to lists all images (`-a` flag) by numeric
80 
-	IDs (`-q` flag) and filter them to find dangling images (`-f
81 
-	dangling=true`). Then, the `docker rmi` command forcibly (`-f` flag) removes
82 
-	the resulting list. To remove just one image, use the `docker rmi ID`
83 
-	command.
57 
+        $ docker images
58 
+
59 
+    You should see something similar to the following:
60 
+
61 
+    <table class="tg code">
62 
+      <tr>
63 
+        <th>REPOSITORY</th>
64 
+        <th>TAG</th>
65 
+        <th>IMAGE ID</th>
66 
+        <th>CREATED</th>
67 
+        <th>VIRTUAL SIZE</th>
68 
+      </tr>
69 
+    </table>
70 
+
71 
+    This host has no images. You may have one or more _dangling_ images. A
72 
+    dangling image is not used by a running container and is not an ancestor of
73 
+    another image on your system. A fast way to remove dangling containers is
74 
+    the following:
75 
+
76 
+        $ docker rmi -f $(docker images -q -a -f dangling=true)
77 
+
78 
+    This command uses `docker images` to lists all images (`-a` flag) by numeric
79 
+    IDs (`-q` flag) and filter them to find dangling images (`-f
80 
+    dangling=true`). Then, the `docker rmi` command forcibly (`-f` flag) removes
81 
+    the resulting list. To remove just one image, use the `docker rmi ID`
82 
+    command.
84 83
85 84
86 85 
 ## Build an image
87 86
88 
-If you followed the last procedure, your host is clean of unnecessary images and containers. In this section, you build an image from the Docker development environment.
87 
+If you followed the last procedure, your host is clean of unnecessary images
88 
+and containers. In this section, you build an image from the Docker development
89 
+environment.
89 90
90 91 
 1. Open a terminal.
91 92
92 
-	Mac users, use `boot2docker status` to make sure Boot2Docker is running. You
93 
-	may need to run `$(boot2docker shellinit)` to initialize your shell
94 
-	environment.
93 
+    Mac users, use `boot2docker status` to make sure Boot2Docker is running. You
94 
+    may need to run `$(boot2docker shellinit)` to initialize your shell
95 
+    environment.
95 96
96 97 
 3. Change into the root of your forked repository.
97 98
98 
-		$ cd ~/repos/docker-fork
99 
+        $ cd ~/repos/docker-fork
99 100
100 101 
 4. Ensure you are on your `dry-run-test` branch.
101 102
102 
-		$ git checkout dry-run-test
103 
+        $ git checkout dry-run-test
103 104
104 105 
 5. Compile your development environment container into an image.
105 106
106 
-		$ docker build -t dry-run-test .
107 
+        $ docker build -t dry-run-test .
107 108
108 
-	The `docker build` command returns informational message as it runs. The
109 
-	first build may take a few minutes to create an image. Using the
110 
-	instructions in the `Dockerfile`, the build may need to download source and
111 
-	other images. A successful build returns a final status message similar to
112 
-	the following:
109 
+    The `docker build` command returns informational message as it runs. The
110 
+    first build may take a few minutes to create an image. Using the
111 
+    instructions in the `Dockerfile`, the build may need to download source and
112 
+    other images. A successful build returns a final status message similar to
113 
+    the following:
113 114
114 
-		 Successfully built 676815d59283
115 
+        Successfully built 676815d59283
115 116
116 117 
 6. List your Docker images again.
117 118
118 
-		$ docker images
119 
-
120 
-	You should see something similar to this:
121 
-		 <style type="text/css">
122 
-	.tg  {border-collapse:collapse;border-spacing:0;} .tg td{font-family:monospace, serif;font-size:11px;padding:5px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;} .tg th{font-family:monospace, serif;font-size:11px;font-weight:normal;padding:5px
123 
-5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
124 
-	</style>
125 
-	<table class="tg">
126 
-	  <tr>
127 
-		<th class="tg-031e">REPOSTITORY</th>
128 
-		<th class="tg-031e">TAG</th>
129 
-		<th class="tg-031e">IMAGE ID</th>
130 
-		<th class="tg-031e">CREATED</th>
131 
-		<th class="tg-031e">VIRTUAL SIZE</th>
132 
-	  </tr>
133 
-	  <tr>
134 
-		<td class="tg-031e">dry-run-test</td>
135 
-		<td class="tg-031e">latest</td>
136 
-		<td class="tg-031e">663fbee70028</td>
137 
-		<td class="tg-031e">About a minute ago</td>
138 
-		<td class="tg-031e"></td>
139 
-	  </tr>
140 
-	  <tr>
141 
-		<td class="tg-031e">ubuntu</td>
142 
-		<td class="tg-031e">trusty</td>
143 
-		<td class="tg-031e">2d24f826cb16</td>
144 
-		<td class="tg-031e">2 days ago</td>
145 
-		<td class="tg-031e">188.3 MB</td>
146 
-	  </tr>
147 
-	  <tr>
148 
-		<td class="tg-031e">ubuntu</td>
149 
-		<td class="tg-031e">trusty-20150218.1</td>
150 
-		<td class="tg-031e">2d24f826cb16</td>
151 
-		<td class="tg-031e">2 days ago</td>
152 
-		<td class="tg-031e">188.3 MB</td>
153 
-	  </tr>
154 
-	  <tr>
155 
-		<td class="tg-031e">ubuntu</td>
156 
-		<td class="tg-031e">14.04</td>
157 
-		<td class="tg-031e">2d24f826cb16</td>
158 
-		<td class="tg-031e">2 days ago</td>
159 
-		<td class="tg-031e">188.3 MB</td>
160 
-	  </tr>
161 
-	  <tr>
162 
-		<td class="tg-031e">ubuntu</td>
163 
-		<td class="tg-031e">14.04.2</td>
164 
-		<td class="tg-031e">2d24f826cb16</td>
165 
-		<td class="tg-031e">2 days ago</td>
166 
-		<td class="tg-031e">188.3 MB</td>
167 
-	  </tr>
168 
-	  <tr>
169 
-		<td class="tg-031e">ubuntu</td>
170 
-		<td class="tg-031e">latest</td>
171 
-		<td class="tg-031e">2d24f826cb16</td>
172 
-		<td class="tg-031e">2 days ago</td>
173 
-		<td class="tg-031e">188.3 MB</td>
174 
-	  </tr>
175 
-	</table>
176 
-
177 
-	Locate your new `dry-run-test` image in the list. You should also see a
178 
-	number of `ubuntu` images. The build process creates these. They are the
179 
-	ancestors of your new Docker development image. When you next rebuild your
180 
-	image, the build process reuses these ancestors images if they exist.
181 
-
182 
-	Keeping the ancestor images improves the build performance. When you rebuild
183 
-	the child image, the build process uses the local ancestors rather than
184 
-	retrieving them from the Hub. The build process gets new ancestors only if
185 
-	DockerHub has updated versions.
119 
+        $ docker images
120 
+
121 
+    You should see something similar to this:
122 
+
123 
+    <table class="tg code">
124 
+      <tr>
125 
+        <th>REPOSTITORY</th>
126 
+        <th>TAG</th>
127 
+        <th>IMAGE ID</th>
128 
+        <th>CREATED</th>
129 
+        <th>VIRTUAL SIZE</th>
130 
+      </tr>
131 
+      <tr>
132 
+        <td>dry-run-test</td>
133 
+        <td>latest</td>
134 
+        <td>663fbee70028</td>
135 
+        <td>About a minute ago</td>
136 
+        <td></td>
137 
+      </tr>
138 
+      <tr>
139 
+        <td>ubuntu</td>
140 
+        <td>trusty</td>
141 
+        <td>2d24f826cb16</td>
142 
+        <td>2 days ago</td>
143 
+        <td>188.3 MB</td>
144 
+      </tr>
145 
+      <tr>
146 
+        <td>ubuntu</td>
147 
+        <td>trusty-20150218.1</td>
148 
+        <td>2d24f826cb16</td>
149 
+        <td>2 days ago</td>
150 
+        <td>188.3 MB</td>
151 
+      </tr>
152 
+      <tr>
153 
+        <td>ubuntu</td>
154 
+        <td>14.04</td>
155 
+        <td>2d24f826cb16</td>
156 
+        <td>2 days ago</td>
157 
+        <td>188.3 MB</td>
158 
+      </tr>
159 
+      <tr>
160 
+        <td>ubuntu</td>
161 
+        <td>14.04.2</td>
162 
+        <td>2d24f826cb16</td>
163 
+        <td>2 days ago</td>
164 
+        <td>188.3 MB</td>
165 
+      </tr>
166 
+      <tr>
167 
+        <td>ubuntu</td>
168 
+        <td>latest</td>
169 
+        <td>2d24f826cb16</td>
170 
+        <td>2 days ago</td>
171 
+        <td>188.3 MB</td>
172 
+      </tr>
173 
+    </table>
174 
+
175 
+    Locate your new `dry-run-test` image in the list. You should also see a
176 
+    number of `ubuntu` images. The build process creates these. They are the
177 
+    ancestors of your new Docker development image. When you next rebuild your
178 
+    image, the build process reuses these ancestors images if they exist.
179 
+
180 
+    Keeping the ancestor images improves the build performance. When you rebuild
181 
+    the child image, the build process uses the local ancestors rather than
182 
+    retrieving them from the Hub. The build process gets new ancestors only if
183 
+    DockerHub has updated versions.
186 184
187 185 
 ## Start a container and run a test
188 186
... ... 
@@ -192,155 +198,153 @@ build and run a `docker` binary in your container.
192 192
193 193 
 1. Open two additional terminals on your host.
194 194
195 
-	At this point, you'll have about three terminals open.
195 
+    At this point, you'll have about three terminals open.
196 196
197 
-	![Multiple terminals](/project/images/three_terms.png)
197 
+    ![Multiple terminals](/project/images/three_terms.png)
198 
+
199 
+    Mac OSX users, make sure you run `$(boot2docker shellinit)` in any new
200 
+    terminals.
198 201
199 
-	Mac OSX users, make sure you run `$(boot2docker shellinit)` in any new
200 
-	terminals.
201 
-
202 202 
 2. In a terminal, create a new container from your `dry-run-test` image.
203 203
204 
-		$ docker run --privileged --rm -ti dry-run-test /bin/bash
205 
-		root@5f8630b873fe:/go/src/github.com/docker/docker#
204 
+        $ docker run --privileged --rm -ti dry-run-test /bin/bash
205 
+        root@5f8630b873fe:/go/src/github.com/docker/docker#
206 206
207 
-	The command creates a container from your `dry-run-test` image. It opens an
208 
-	interactive terminal (`-ti`) running a `/bin/bash shell`.  The
209 
-	`--privileged` flag gives the container access to kernel features and device
210 
-	access. It is this flag that allows you to run a container in a container.
211 
-	Finally, the `-rm` flag instructs Docker to remove the container when you
212 
-	exit the `/bin/bash` shell.
213 
-
214 
-	The container includes the source of your image repository in the
215 
-	`/go/src/github.com/docker/docker` directory. Try listing the contents to
216 
-	verify they are the same as that of your `docker-fork` repo.
217 
-
218 
-	![List example](/project/images/list_example.png)
207 
+    The command creates a container from your `dry-run-test` image. It opens an
208 
+    interactive terminal (`-ti`) running a `/bin/bash shell`.  The
209 
+    `--privileged` flag gives the container access to kernel features and device
210 
+    access. It is this flag that allows you to run a container in a container.
211 
+    Finally, the `-rm` flag instructs Docker to remove the container when you
212 
+    exit the `/bin/bash` shell.
213 
+
214 
+    The container includes the source of your image repository in the
215 
+    `/go/src/github.com/docker/docker` directory. Try listing the contents to
216 
+    verify they are the same as that of your `docker-fork` repo.
217 
+
218 
+    ![List example](/project/images/list_example.png)
219 219
220 220
221 221 
 3. Investigate your container bit.
222 222
223 
-	If you do a `go version` you'll find the `go` language is part of the
224 
-	container.
225 
-
226 
-		root@31ed86e9ddcf:/go/src/github.com/docker/docker# go version
227 
-		go version go1.4.2 linux/amd64
228 
-
229 
-	Similarly, if you do a `docker version` you find the container
230 
-	has no `docker` binary.
231 
-
232 
-		root@31ed86e9ddcf:/go/src/github.com/docker/docker# docker version
233 
-		bash: docker: command not found
234 
-
235 
-	You will create one in the next steps.
236 
-
223 
+    If you do a `go version` you'll find the `go` language is part of the
224 
+    container.
225 
+
226 
+        root@31ed86e9ddcf:/go/src/github.com/docker/docker# go version
227 
+        go version go1.4.2 linux/amd64
228 
+
229 
+    Similarly, if you do a `docker version` you find the container
230 
+    has no `docker` binary.
231 
+
232 
+        root@31ed86e9ddcf:/go/src/github.com/docker/docker# docker version
233 
+        bash: docker: command not found
234 
+
235 
+    You will create one in the next steps.
236 
+
237 237 
 4. From the `/go/src/github.com/docker/docker` directory make a `docker` binary with the `make.sh` script.
238 238
239 
-		root@5f8630b873fe:/go/src/github.com/docker/docker# project/make.sh binary
239 
+        root@5f8630b873fe:/go/src/github.com/docker/docker# project/make.sh binary
240 
+
240 241 
     You only call `project/make.sh` to build a binary _inside_ a Docker
241 
-	development container as you are now. On your host, you'll use `make`
242 
-	commands (more about this later).
243 
-
244 
-	As it makes the binary, the `make.sh` script reports the build's progress.
245 
-	When the command completes successfully, you should see the following
246 
-	output:
247 
-
248 
-		---> Making bundle: ubuntu (in bundles/1.5.0-dev/ubuntu)
249 
-		Created package {:path=>"lxc-docker-1.5.0-dev_1.5.0~dev~git20150223.181106.0.1ab0d23_amd64.deb"}
250 
-		Created package {:path=>"lxc-docker_1.5.0~dev~git20150223.181106.0.1ab0d23_amd64.deb"}
242 
+    development container as you are now. On your host, you'll use `make`
243 
+    commands (more about this later).
244 
+
245 
+    As it makes the binary, the `make.sh` script reports the build's progress.
246 
+    When the command completes successfully, you should see the following
247 
+    output:
248 
+
249 
+        ---> Making bundle: ubuntu (in bundles/1.5.0-dev/ubuntu)
250 
+        Created package {:path=>"lxc-docker-1.5.0-dev_1.5.0~dev~git20150223.181106.0.1ab0d23_amd64.deb"}
251 
+        Created package {:path=>"lxc-docker_1.5.0~dev~git20150223.181106.0.1ab0d23_amd64.deb"}
251 252
252 
-
253 253 
 5. List all the contents of the `binary` directory.
254 254
255 
-		root@5f8630b873fe:/go/src/github.com/docker/docker#  ls bundles/1.5.0-dev/binary/
256 
-		docker  docker-1.5.0-dev  docker-1.5.0-dev.md5  docker-1.5.0-dev.sha256
257 
-
258 
-	  You should see that `binary` directory, just as it sounds, contains the
259 
-	  made binaries.
255 
+        root@5f8630b873fe:/go/src/github.com/docker/docker#  ls bundles/1.5.0-dev/binary/
256 
+        docker  docker-1.5.0-dev  docker-1.5.0-dev.md5  docker-1.5.0-dev.sha256
257 
+
258 
+    You should see that `binary` directory, just as it sounds, contains the
259 
+    made binaries.
260 260
261 261
262 262 
 6. Copy the `docker` binary to the `/usr/bin` of your container.
263 263
264 
-		root@5f8630b873fe:/go/src/github.com/docker/docker#  cp bundles/1.5.0-dev/binary/docker /usr/bin
265 
-
264 
+        root@5f8630b873fe:/go/src/github.com/docker/docker#  cp bundles/1.5.0-dev/binary/docker /usr/bin
265 
+
266 266 
 7. Inside your container, check your Docker version.
267 267
268 
-	root@5f8630b873fe:/go/src/github.com/docker/docker# docker --version
269 
-	Docker version 1.5.0-dev, build 6e728fb
270 
-
271 
-	Inside the container you are running a development version. This is version
272 
-	on the current branch it reflects the value of the `VERSION` file at the
273 
-	root of your `docker-fork` repository.
268 
+        root@5f8630b873fe:/go/src/github.com/docker/docker# docker --version
269 
+        Docker version 1.5.0-dev, build 6e728fb
270 
+
271 
+    Inside the container you are running a development version. This is version
272 
+    on the current branch it reflects the value of the `VERSION` file at the
273 
+    root of your `docker-fork` repository.
274 274
275 275 
 8. Start a `docker` daemon running inside your container.
276 276
277 
-		root@5f8630b873fe:/go/src/github.com/docker/docker#  docker -dD
278 
-
279 
-	The `-dD` flag starts the daemon in debug mode; You'll find this useful
280 
-	when debugging your code.
281 
-
277 
+        root@5f8630b873fe:/go/src/github.com/docker/docker#  docker -dD
278 
+
279 
+    The `-dD` flag starts the daemon in debug mode; You'll find this useful
280 
+    when debugging your code.
281 
+
282 282 
 9. Bring up one of the terminals on your local host.
283 283
284 284
285 285 
 10. List your containers and look for the container running the `dry-run-test` image.
286 286
287 
-		$ docker ps
288 
-
289 
-	<style type="text/css">
290 
-	.tg  {border-collapse:collapse;border-spacing:0;} .tg td{font-family:monospace, serif;font-size:11px;padding:5px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;} .tg th{font-family:monospace, sans-serif;font-size:11px;font-weight:normal;padding:5px
291 
-5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
292 
-	</style>
293 
-	<table class="tg">
294 
-	  <tr>
295 
-		<th class="tg-031e">CONTAINER ID</th>
296 
-		<th class="tg-031e">IMAGE</th>
297 
-		<th class="tg-031e">COMMAND</th>
298 
-		<th class="tg-031e">CREATED</th>
299 
-		<th class="tg-031e">STATUS</th>
300 
-		<th class="tg-031e">PORTS</th>
301 
-		<th class="tg-031e">NAMES</th>
302 
-	  </tr>
303 
-	  <tr>
304 
-		<td class="tg-031e">474f07652525</td>
305 
-		<td class="tg-031e">dry-run-test:latest</td>
306 
-		<td class="tg-031e">"hack/dind /bin/bash</td>
307 
-		<td class="tg-031e">14 minutes ago</td>
308 
-		<td class="tg-031e">Up 14 minutes</td>
309 
-		<td class="tg-031e"></td>
310 
-		<td class="tg-031e">tender_shockley</td>
311 
-	  </tr>
312 
-	</table>
313 
-
314 
-	In this example, the container's name is `tender_shockley`; yours will be
315 
-	different.
316 
-
287 
+        $ docker ps
288 
+
289 
+    <table class="tg code">
290 
+      <tr>
291 
+        <th>CONTAINER ID</th>
292 
+        <th>IMAGE</th>
293 
+        <th>COMMAND</th>
294 
+        <th>CREATED</th>
295 
+        <th>STATUS</th>
296 
+        <th>PORTS</th>
297 
+        <th>NAMES</th>
298 
+      </tr>
299 
+      <tr>
300 
+        <td>474f07652525</td>
301 
+        <td>dry-run-test:latest</td>
302 
+        <td>"hack/dind /bin/bash</td>
303 
+        <td>14 minutes ago</td>
304 
+        <td>Up 14 minutes</td>
305 
+        <td></td>
306 
+        <td>tender_shockley</td>
307 
+      </tr>
308 
+    </table>
309 
+
310 
+    In this example, the container's name is `tender_shockley`; yours will be
311 
+    different.
312 
+
317 313 
 11. From the terminal, start another shell on your Docker development container.
318 314
319 
-		$ docker exec -it tender_shockley bash
320 
-
321 
-	At this point, you have two terminals both with a shell open into your
322 
-	development container. One terminal is running a debug session. The other
323 
-	terminal is displaying a `bash` prompt.
315 
+        $ docker exec -it tender_shockley bash
316 
+
317 
+    At this point, you have two terminals both with a shell open into your
318 
+    development container. One terminal is running a debug session. The other
319 
+    terminal is displaying a `bash` prompt.
324 320
325 321 
 12. At the prompt, test the Docker client by running the `hello-world` container.
326 322
327 
-		root@9337c96e017a:/go/src/github.com/docker/docker#  docker run hello-world
328 
-
329 
-	You should see the image load and return. Meanwhile, you
330 
-	can see the calls made via the debug session in your other terminal.
323 
+        root@9337c96e017a:/go/src/github.com/docker/docker#  docker run hello-world
324 
+
325 
+    You should see the image load and return. Meanwhile, you
326 
+    can see the calls made via the debug session in your other terminal.
327 
+
328 
+    ![List example](/project/images/three_running.png)
329 
+
331 330
332 
-	![List example](/project/images/three_running.png)
333 
-
334 
-
335 331 
 ## Restart a container with your source
336 332
337 
-At this point, you have experienced the "Docker inception" technique. That is, you have:
333 
+At this point, you have experienced the "Docker inception" technique. That is,
334 
+you have:
338 335
339 336 
 * built a Docker image from the Docker repository
340 337 
 * created and started a Docker development container from that image
341 338 
 * built a Docker binary inside of your Docker development container
342 339 
 * launched a `docker` daemon using your newly compiled binary
343 
-* called the `docker` client to run a `hello-world` container inside your development container
340 
+* called the `docker` client to run a `hello-world` container inside
341 
+  your development container
344 342
345 343 
 When you really get to developing code though, you'll want to iterate code
346 344 
 changes and builds inside the container. For that you need to mount your local
... ... 
@@ -349,67 +353,67 @@ Docker repository source into your Docker container. Try that now.
349 349 
 1. If you haven't already, exit out of BASH shells in your running Docker
350 350 
 container.
351 351
352 
-	If you have followed this guide exactly, exiting out your BASH shells stops
353 
-	the running container. You can use the `docker ps` command to verify the
354 
-	development container is stopped. All of your terminals should be at the
355 
-	local host prompt.
356 
-
352 
+    If you have followed this guide exactly, exiting out your BASH shells stops
353 
+    the running container. You can use the `docker ps` command to verify the
354 
+    development container is stopped. All of your terminals should be at the
355 
+    local host prompt.
356 
+
357 357 
 2. Choose a terminal and make sure you are in your `docker-fork` repository.
358 358
359 
-		$ pwd
360 
-		/Users/mary/go/src/github.com/moxiegirl/docker-fork
361 
-
362 
-	Your location will be different because it reflects your environment.
359 
+        $ pwd
360 
+        /Users/mary/go/src/github.com/moxiegirl/docker-fork
361 
+
362 
+    Your location will be different because it reflects your environment.
363 363
364 364 
 3. Create a container using `dry-run-test` but this time mount your repository onto the `/go` directory inside the container.
365 365
366 
-	 	$  docker run --privileged --rm -ti -v `pwd`:/go/src/github.com/docker/docker dry-run-test /bin/bash
366 
+        $  docker run --privileged --rm -ti -v `pwd`:/go/src/github.com/docker/docker dry-run-test /bin/bash
367 367
368 
-	When you pass `pwd`, `docker` resolves it to your current directory.
368 
+    When you pass `pwd`, `docker` resolves it to your current directory.
369 369
370 370 
 4. From inside the container, list your `binary` directory.
371 371
372 
-		root@074626fc4b43:/go/src/github.com/docker/docker# ls bundles/1.5.0-dev/binary
373 
-		ls: cannot access binary: No such file or directory
374 
-
375 
-	Your `dry-run-test` image does not retain any of the changes you made inside
376 
-	the container.  This is the expected behavior for a container.
377 
-
372 
+        root@074626fc4b43:/go/src/github.com/docker/docker# ls bundles/1.5.0-dev/binary
373 
+        ls: cannot access binary: No such file or directory
374 
+
375 
+    Your `dry-run-test` image does not retain any of the changes you made inside
376 
+    the container.  This is the expected behavior for a container.
377 
+
378 378 
 5. In a fresh terminal on your local host, change to the `docker-fork` root.
379 379
380 
-	$ cd ~/repos/docker-fork/
380 
+        $ cd ~/repos/docker-fork/
381 381
382 382 
 6. Create a fresh binary but this time use the `make` command.
383 383
384 
-		$ make BINDDIR=. binary
385 
-
386 
-	The `BINDDIR` flag is only necessary on Mac OS X but it won't hurt to pass
387 
-	it on Linux command line. The `make` command, like the `make.sh` script
388 
-	inside the container, reports its progress. When the make succeeds, it
389 
-	returns the location of the new binary.
390 
-
384 
+        $ make BINDDIR=. binary
385 
+
386 
+    The `BINDDIR` flag is only necessary on Mac OS X but it won't hurt to pass
387 
+    it on Linux command line. The `make` command, like the `make.sh` script
388 
+    inside the container, reports its progress. When the make succeeds, it
389 
+    returns the location of the new binary.
390 
+
391 391
392 392 
 7. Back in the terminal running the container, list your `binary` directory.
393 393
394 
-		root@074626fc4b43:/go/src/github.com/docker/docker# ls bundles/1.5.0-dev/binary
395 
-		docker	docker-1.5.0-dev  docker-1.5.0-dev.md5	docker-1.5.0-dev.sha256
396 
-
397 
-	The compiled binaries created from your repository on your local host are
398 
-	now available inside your running Docker development container.
399 
-
400 
-8. Repeat the steps you ran in the previous procedure.
394 
+        root@074626fc4b43:/go/src/github.com/docker/docker# ls bundles/1.5.0-dev/binary
395 
+        docker	docker-1.5.0-dev  docker-1.5.0-dev.md5	docker-1.5.0-dev.sha256
401 396
402 
-	* copy the binary inside the development container using
403 
-		`cp bundles/1.5.0-dev/binary/docker /usr/bin`
404 
-	* start `docker -dD` to launch the Docker daemon inside the container
405 
-	* run `docker ps` on local host to get the development container's name
406 
-	* connect to your running container `docker exec -it container_name bash`
407 
-	* use the `docker run hello-world` command to create and run a container inside your development container
408 
-
409 
-
410 
-## Where to go next
397 
+    The compiled binaries created from your repository on your local host are
398 
+    now available inside your running Docker development container.
399 
+
400 
+8. Repeat the steps you ran in the previous procedure.
411 401
412 
-Congratulations, you have successfully achieved Docker inception. At this point, you've set up your development environment and verified almost all the essential processes you need to contribute. Of course, before you start contributing, [you'll need to learn one more piece of the development environment, the test framework](/project/test-and-docs/).
402 
+    * copy the binary inside the development container using
403 
+      `cp bundles/1.5.0-dev/binary/docker /usr/bin`
404 
+    * start `docker -dD` to launch the Docker daemon inside the container
405 
+    * run `docker ps` on local host to get the development container's name
406 
+    * connect to your running container `docker exec -it container_name bash`
407 
+    * use the `docker run hello-world` command to create and run a container
408 
+      inside your development container
413 409
414 
-
410 
+## Where to go next
415 411
412 
+Congratulations, you have successfully achieved Docker inception. At this point,
413 
+you've set up your development environment and verified almost all the essential
414 
+processes you need to contribute. Of course, before you start contributing,
415 
+[you'll need to learn one more piece of the development environment, the test framework](/project/test-and-docs/).
docs/sources/project/set-up-prereqs.md
History View file @ efc625f
... ... 
@@ -4,7 +4,9 @@ page_keywords: GitHub account, repository, clone, fork, branch, upstream, Git, G
4 4
5 5 
 # Set up the prerequisites
6 6
7 
-Work through this page to set up the software and host environment you need to contribute. You'll find instructions for configuring your `git` repository and creating a fork you'll use later in the guide.
7 
+Work through this page to set up the software and host environment you need to
8 
+contribute. You'll find instructions for configuring your `git` repository and
9 
+creating a fork you'll use later in the guide.
8 10
9 11 
 ## Get the Required Software
10 12
... ... 
@@ -15,7 +17,9 @@ Before you begin contributing you must have:
15 15 
 * `make`
16 16 
 * `docker`
17 17
18 
-You'll notice that `go`, the language that Docker is written in, is not listed. That's because you don't need it installed; Docker's development environment provides it for you. You'll learn more about the development environment later.
18 
+You'll notice that `go`, the language that Docker is written in, is not listed.
19 
+That's because you don't need it installed; Docker's development environment
20 
+provides it for you. You'll learn more about the development environment later.
19 21
20 22 
 ### Get a GitHub account
21 23
... ... 
@@ -23,58 +27,66 @@ To contribute to the Docker project, you will need a <a
23 23 
 href="https://github.com" target="_blank">GitHub account</a>. A free account is
24 24 
 fine. All the Docker project repositories are public and visible to everyone.
25 25
26 
-You should also have some experience using both the GitHub application and `git` on the command line.
26 
+You should also have some experience using both the GitHub application and `git`
27 
+on the command line.
27 28
28 29 
 ### Install git
29 30
30 31 
 Install `git` on your local system. You can check if `git` is on already on your
31 32 
 system and properly installed with the following command:
32 33
33 
-	$ git --version
34 
+    $ git --version
34 35
35 36
36 
-This documentation is written using `git` version 2.2.2. Your version may be different depending on your OS.
37 
+This documentation is written using `git` version 2.2.2. Your version may be
38 
+different depending on your OS.
37 39
38 40 
 ### Install make
39 41
40 42 
 Install `make`. You can check if `make` is on your system with the following
41 43 
 command:
42 44
43 
-	$ make -v
45 
+    $ make -v
44 46
45 
-This documentation is written using GNU Make 3.81. Your version may be different depending on your OS.
47 
+This documentation is written using GNU Make 3.81. Your version may be different
48 
+depending on your OS.
46 49
47 50 
 ### Install or upgrade Docker
48 51
49 
-If you haven't already, install the Docker software using the <a href="/installation" target="_blank">instructions for your operating system</a>. If you have an existing installation, check your version and make sure you have the latest Docker.
52 
+If you haven't already, install the Docker software using the
53 
+<a href="/installation" target="_blank">instructions for your operating system</a>.
54 
+If you have an existing installation, check your version and make sure you have
55 
+the latest Docker.
50 56
51 57 
 To check if `docker` is already installed on Linux:
52 58
53 
-	$ docker --version
54 
-	Docker version 1.5.0, build a8a31ef
59 
+    $ docker --version
60 
+    Docker version 1.5.0, build a8a31ef
55 61
56 62 
 On Mac OS X or Windows, you should have installed Boot2Docker which includes
57 63 
 Docker. You'll need to verify both Boot2Docker and then Docker. This
58 64 
 documentation was written on OS X using the following versions.
59 65
66 
+    $ boot2docker version
67 
+    Boot2Docker-cli version: v1.5.0
68 
+    Git commit: ccd9032
60 69
61 
-	$ boot2docker version
62 
-	Boot2Docker-cli version: v1.5.0
63 
-	Git commit: ccd9032
64 
-
65 
-	$ docker --version
66 
-	Docker version 1.5.0, build a8a31ef
70 
+    $ docker --version
71 
+    Docker version 1.5.0, build a8a31ef
67 72
68 73 
 ## Linux users and sudo
69 74
70 
-This guide assumes you have added your user to the `docker` group on your system. To check, list the group's contents:
75 
+This guide assumes you have added your user to the `docker` group on your system.
76 
+To check, list the group's contents:
71 77
72 
-	$ getent group docker
73 
-	docker:x:999:ubuntu
78 
+    $ getent group docker
79 
+    docker:x:999:ubuntu
74 80
75 
-If the command returns no matches, you have two choices. You can preface this guide's `docker` commands with `sudo` as you work. Alternatively, you can add your user to the `docker` group as follows:
81 
+If the command returns no matches, you have two choices. You can preface this
82 
+guide's `docker` commands with `sudo` as you work. Alternatively, you can add
83 
+your user to the `docker` group as follows:
76 84
77 
- 	$ sudo usermod -aG docker ubuntu
85 
+    $ sudo usermod -aG docker ubuntu
78 86
79 87 
 You must log out and back in for this modification to take effect.
80 88
... ... 
@@ -82,7 +94,8 @@ You must log out and back in for this modification to take effect.
82 82 
 ## Fork and clone the Docker code
83 83
84 84 
 When contributing, you first fork the Docker code repository. A fork copies
85 
-a repository at a particular point in time. GitHub tracks for you where a fork originates.
85 
+a repository at a particular point in time. GitHub tracks for you where a fork
86 
+originates.
86 87
87 88 
 As you make contributions, you change your fork's code. When you are ready,
88 89 
 you make a pull request back to the original Docker repository. If you aren't
... ... 
@@ -97,202 +110,209 @@ To fork and clone Docker:
97 97
98 98 
 3. Click the "Fork" button in the upper right corner of the GitHub interface.
99 99
100 
-	![Branch Signature](/project/images/fork_docker.png)
100 
+    ![Branch Signature](/project/images/fork_docker.png)
101 
+
102 
+    GitHub forks the repository to your GitHub account. The original
103 
+    `docker/docker` repository becomes a new fork `YOUR_ACCOUNT/docker` under
104 
+    your account.
101 105
102 
-	GitHub forks the repository to your GitHub account. The original
103 
-	`docker/docker` repository becomes a new fork `YOUR_ACCOUNT/docker` under
104 
-	your account.
105 
-
106 106 
 4. Copy your fork's clone URL from GitHub.
107 107
108 
-	GitHub allows you to use HTTPS or SSH protocols for clones. You can use the
109 
-	`git` command line or clients like Subversion to clone a repository.
110 
-
111 
-	![Copy clone URL](/project/images/copy_url.png)
112 
-
113 
-	This guide assume you are using the HTTPS protocol and the `git` command
114 
-	line. If you are comfortable with SSH and some other tool, feel free to use
115 
-	that instead. You'll need to convert what you see in the guide to what is
116 
-	appropriate to your tool.
117 
-
108 
+    GitHub allows you to use HTTPS or SSH protocols for clones. You can use the
109 
+    `git` command line or clients like Subversion to clone a repository.
110 
+
111 
+    ![Copy clone URL](/project/images/copy_url.png)
112 
+
113 
+    This guide assume you are using the HTTPS protocol and the `git` command
114 
+    line. If you are comfortable with SSH and some other tool, feel free to use
115 
+    that instead. You'll need to convert what you see in the guide to what is
116 
+    appropriate to your tool.
117 
+
118 118 
 5. Open a terminal window on your local host and change to your home directory.
119 119
120 
-		$ cd ~
121 
-
120 
+        $ cd ~
121 
+
122 122 
 6. Create a `repos` directory.
123 123
124 
-		$ mkdir repos
124 
+        $ mkdir repos
125 125
126 126 
 7. Change into your `repos` directory.
127 127
128 
-		$ cd repos
128 
+        $ cd repos
129 129
130 
-5. Clone the fork to your local host into a repository called `docker-fork`.
130 
+5. Clone the fork to your local host into a repository called `docker-fork`.
131 
+
132 
+        $ git clone https://github.com/moxiegirl/docker.git docker-fork
133 
+
134 
+    Naming your local repo `docker-fork` should help make these instructions
135 
+    easier to follow; experienced coders don't typically change the name.
131 136
132 
-		$ git clone https://github.com/moxiegirl/docker.git docker-fork
133 
-
134 
-	Naming your local repo `docker-fork` should help make these instructions
135 
-	easier to follow; experienced coders don't typically change the name.
136 
-
137 137 
 6. Change directory into your new `docker-fork` directory.
138 138
139 
-		$ cd docker-fork
140 
-
141 
-	Take a moment to familiarize yourself with the repository's contents. List
142 
-	the contents.
143 
-
144 
-
139 
+        $ cd docker-fork
140 
+
141 
+    Take a moment to familiarize yourself with the repository's contents. List
142 
+    the contents.
143 
+
145 144 
 ##  Set your signature and an upstream remote
146 145
147 
-When you contribute to Docker, you must certify you agree with the <a href="http://developercertificate.org/" target="_blank">Developer Certificate of Origin</a>. You indicate your agreement by signing your `git` commits like this:
146 
+When you contribute to Docker, you must certify you agree with the
147 
+<a href="http://developercertificate.org/" target="_blank">Developer Certificate of Origin</a>.
148 
+You indicate your agreement by signing your `git` commits like this:
148 149
149 
-	Signed-off-by: Pat Smith <pat.smith@email.com>
150 
+    Signed-off-by: Pat Smith <pat.smith@email.com>
150 151
151 
-To create a signature, you configure your username and email address in Git. You can set these globally or locally on just your `docker-fork` repository.  You must sign with your real name. We don't accept anonymous contributions or contributions through pseudonyms.
152 
+To create a signature, you configure your username and email address in Git.
153 
+You can set these globally or locally on just your `docker-fork` repository.
154 
+You must sign with your real name. We don't accept anonymous contributions or
155 
+contributions through pseudonyms.
152 156
153 
-As you change code in your fork, you'll want to keep it in sync with the changes others make in the `docker/docker` repository.  To make syncing easier, you'll also add a _remote_ called `upstream` that points to `docker/docker`. A remote is just another a project version hosted on the internet or network.
157 
+As you change code in your fork, you'll want to keep it in sync with the changes
158 
+others make in the `docker/docker` repository.  To make syncing easier, you'll
159 
+also add a _remote_ called `upstream` that points to `docker/docker`. A remote
160 
+is just another a project version hosted on the internet or network.
154 161
155 162 
 To configure your username, email, and add a remote:
156 
-
163 
+
157 164 
 1. Change to the root of your `docker-fork` repository.
158 165
159 
-		$ cd docker-fork
166 
+        $ cd docker-fork
167 
+
168 
+2. Set your `user.name` for the repository.
160 169
161 
-2. 	Set your `user.name` for the repository.
170 
+        $ git config --local user.name "FirstName LastName"
162 171
163 
-		$ git config --local user.name "FirstName LastName"
164 
-
165 172 
 3. Set your `user.email` for the repository.
166 173
167 
-		$ git config --local user.email "emailname@mycompany.com"
168 
-
174 
+        $ git config --local user.email "emailname@mycompany.com"
175 
+
169 176 
 4. Set your local repo to track changes upstream, on the `docker` repository.
170 177
171 
-		$ git remote add upstream https://github.com/docker/docker.git
178 
+        $ git remote add upstream https://github.com/docker/docker.git
172 179
173 180 
 7. Check the result in your `git` configuration.
174 181
175 
-		$ git config --local -l
176 
-		core.repositoryformatversion=0
177 
-		core.filemode=true
178 
-		core.bare=false
179 
-		core.logallrefupdates=true
180 
-		remote.origin.url=https://github.com/moxiegirl/docker.git
181 
-		remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
182 
-		branch.master.remote=origin
183 
-		branch.master.merge=refs/heads/master
184 
-		user.name=Mary Anthony
185 
-		user.email=mary@docker.com
186 
-		remote.upstream.url=https://github.com/docker/docker.git
187 
-		remote.upstream.fetch=+refs/heads/*:refs/remotes/upstream/*
182 
+        $ git config --local -l
183 
+        core.repositoryformatversion=0
184 
+        core.filemode=true
185 
+        core.bare=false
186 
+        core.logallrefupdates=true
187 
+        remote.origin.url=https://github.com/moxiegirl/docker.git
188 
+        remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
189 
+        branch.master.remote=origin
190 
+        branch.master.merge=refs/heads/master
191 
+        user.name=Mary Anthony
192 
+        user.email=mary@docker.com
193 
+        remote.upstream.url=https://github.com/docker/docker.git
194 
+        remote.upstream.fetch=+refs/heads/*:refs/remotes/upstream/*
188 195
189 196 
 	To list just the remotes use:
190 
-
191 
-		$ git remote -v
192 
-		origin	https://github.com/moxiegirl/docker.git (fetch)
193 
-		origin	https://github.com/moxiegirl/docker.git (push)
194 
-		upstream	https://github.com/docker/docker.git (fetch)
195 
-		upstream	https://github.com/docker/docker.git (push)
196 
-
197 
-
198 
-
197 
+
198 
+        $ git remote -v
199 
+        origin	https://github.com/moxiegirl/docker.git (fetch)
200 
+        origin	https://github.com/moxiegirl/docker.git (push)
201 
+        upstream	https://github.com/docker/docker.git (fetch)
202 
+        upstream	https://github.com/docker/docker.git (push)
203 
+
199 204 
 ## Create and push a branch
200 205
201 
-As you change code in your fork, you make your changes on a repository branch. The branch name should reflect what you are working on. In this section, you create a branch, make a change, and push it up to your fork.
206 
+As you change code in your fork, you make your changes on a repository branch.
207 
+The branch name should reflect what you are working on. In this section, you
208 
+create a branch, make a change, and push it up to your fork.
202 209
203 
-This branch is just for testing your config for this guide. The changes are part of a dry run so the branch name is going to be dry-run-test. To create an push the branch to your fork on GitHub:
210 
+This branch is just for testing your config for this guide. The changes arepart
211 
+of a dry run so the branch name is going to be dry-run-test. To create an push
212 
+the branch to your fork on GitHub:
204 213
205 214 
 1. Open a terminal and go to the root of your `docker-fork`.
206 215
207 
-		$ cd docker-fork
216 
+        $ cd docker-fork
208 217
209 218 
 2. Create a `dry-run-test` branch.
210 219
211 
-		$ git checkout -b dry-run-test
212 
-
213 
-	This command creates the branch and switches the repository to it.
220 
+        $ git checkout -b dry-run-test
221 
+
222 
+    This command creates the branch and switches the repository to it.
214 223
215 224 
 3. Verify you are in your new branch.
216 225
217 
-		$ git branch
218 
-		* dry-run-test
219 
-  		  master
220 
-
221 
-  	The current branch has an * (asterisk) marker. So, these results shows you
222 
- 	are on the right branch.
223 
-
226 
+        $ git branch
227 
+        * dry-run-test
228 
+          master
229 
+
230 
+    The current branch has an * (asterisk) marker. So, these results shows you
231 
+    are on the right branch.
232 
+
224 233 
 4. Create a `TEST.md` file in the repository's root.
225 234
226 
-		$ touch TEST.md
235 
+        $ touch TEST.md
227 236
228 237 
 5. Edit the file and add your email and location.
229 238
230 
-	![Add your information](/project/images/contributor-edit.png)
231 
-
232 
-	You can use any text editor you are comfortable with.
239 
+    ![Add your information](/project/images/contributor-edit.png)
240 
+
241 
+    You can use any text editor you are comfortable with.
233 242
234 243 
 6. Close and save the file.
235 244
236 245 
 7. Check the status of your branch.
237 246
238 
-		$ git status
239 
-		On branch dry-run-test
240 
-		Untracked files:
241 
-		  (use "git add <file>..." to include in what will be committed)
247 
+        $ git status
248 
+        On branch dry-run-test
249 
+        Untracked files:
250 
+          (use "git add <file>..." to include in what will be committed)
251 
+
252 
+            TEST.md
253 
+
254 
+        nothing added to commit but untracked files present (use "git add" to track)
242 255
243 
-			TEST.md
244 
-
245 
-		nothing added to commit but untracked files present (use "git add" to track)
246 
-
247 256 
 	You've only changed the one file. It is untracked so far by git.
248 
-
257 
+
249 258 
 8. Add your file.
250 259
251 
-		$ git add TEST.md
252 
-
253 
-	That is the only _staged_ file. Stage is fancy word for work that Git is
254 
-	tracking.
260 
+        $ git add TEST.md
255 261
256 
-9. Sign and commit your change.
262 
+    That is the only _staged_ file. Stage is fancy word for work that Git is
263 
+    tracking.
257 264
258 
-		$ git -s -m "Making a dry run test."
259 
-		[dry-run-test 6e728fb] Making a dry run test
260 
-		 1 file changed, 1 insertion(+)
261 
-		 create mode 100644 TEST.md
265 
+9. Sign and commit your change.
262 266
267 
+        $ git -s -m "Making a dry run test."
268 
+        [dry-run-test 6e728fb] Making a dry run test
269 
+         1 file changed, 1 insertion(+)
270 
+         create mode 100644 TEST.md
263 271
264 
-	Commit messages should have a short summary sentence of no more than 50
265 
-	characters. Optionally, you can also include a more detailed explanation
266 
-	after the summary. Separate the summary from any explanation with an empty
267 
-	line.
272 
+    Commit messages should have a short summary sentence of no more than 50
273 
+    characters. Optionally, you can also include a more detailed explanation
274 
+    after the summary. Separate the summary from any explanation with an empty
275 
+    line.
268 276
269 277 
 8. Push your changes to GitHub.
270 278
271 
-   	 	$ git push --set-upstream origin dry-run-test
272 
-		Username for 'https://github.com': moxiegirl
273 
-		Password for 'https://moxiegirl@github.com':
274 
-
275 
-	Git prompts you for your GitHub username and password. Then, the command
276 
-	returns a result.
277 
-
278 
-		Counting objects: 13, done.
279 
-		Compressing objects: 100% (2/2), done.
280 
-		Writing objects: 100% (3/3), 320 bytes | 0 bytes/s, done.
281 
-		Total 3 (delta 1), reused 0 (delta 0)
282 
-		To https://github.com/moxiegirl/docker.git
283 
-		 * [new branch]      dry-run-test -> dry-run-test
284 
-		Branch dry-run-test set up to track remote branch dry-run-test from origin.
285 
-
286 
-
279 
+        $ git push --set-upstream origin dry-run-test
280 
+        Username for 'https://github.com': moxiegirl
281 
+        Password for 'https://moxiegirl@github.com':
282 
+
283 
+    Git prompts you for your GitHub username and password. Then, the command
284 
+    returns a result.
285 
+
286 
+        Counting objects: 13, done.
287 
+        Compressing objects: 100% (2/2), done.
288 
+        Writing objects: 100% (3/3), 320 bytes | 0 bytes/s, done.
289 
+        Total 3 (delta 1), reused 0 (delta 0)
290 
+        To https://github.com/moxiegirl/docker.git
291 
+         * [new branch]      dry-run-test -> dry-run-test
292 
+        Branch dry-run-test set up to track remote branch dry-run-test from origin.
293 
+
287 294 
 9. Open your browser to Github.
288 295
289 296 
 10. Navigate to your Docker fork.
290 297
291 298 
 11. Make sure the `dry-run-test` branch exists, that it has your commit, and the commit is signed.
292 299
293 
-	![Branch Signature](/project/images/branch-sig.png)
300 
+    ![Branch Signature](/project/images/branch-sig.png)
294 301
295 
-
296 302 
 ## Where to go next
297 303
298 
-Congratulations, you have set up and validated the contributor requirements. In the next section you'll [learn how to set up and work in a Docker development container](/project/set-up-dev-env/).
299 304 
\ No newline at end of file
305 
+Congratulations, you have set up and validated the contributor requirements.
306 
+In the next section you'll [learn how to set up and work in a Docker development container](/project/set-up-dev-env/).
docs/sources/project/test-and-docs.md
History View file @ efc625f
... ... 
@@ -2,6 +2,13 @@ page_title: Run tests and test documentation
2 2 
 page_description: Describes Docker's testing infrastructure
3 3 
 page_keywords: make test, make docs, Go tests, gofmt, contributing, running tests
4 4
5 
+<!-- TODO (@thaJeztah) remove after docs/base is updated -->
6 
+<style type="text/css">
7 
+.tg  {border-collapse:collapse;border-spacing:0;margin-bottom:15px;}
8 
+.tg td{padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
9 
+.tg th{padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;text-align:left;}
10 
+</style>
11 
+
5 12 
 # Run tests and test documentation
6 13
7 14 
 Contributing includes testing your changes. If you change the Docker code, you
... ... 
@@ -9,9 +16,15 @@ may need to add a new test or modify an existing one. Your contribution could
9 9 
 even be adding tests to Docker. For this reason, you need to know a little
10 10 
 about Docker's test infrastructure.
11 11
12 
-Many contributors contribute documentation only. Or, a contributor makes a code contribution that changes how Docker behaves and that change needs documentation. For these reasons, you also need to know how to build, view, and test the Docker documentation.
12 
+Many contributors contribute documentation only. Or, a contributor makes a code
13 
+contribution that changes how Docker behaves and that change needs
14 
+documentation. For these reasons, you also need to know how to build, view, and
15 
+test the Docker documentation.
13 16
14 
-In this section, you run tests in the `dry-run-test` branch of your Docker fork. If you have followed along in this guide, you already have this branch. If you don't have this branch, you can create it or simply use another of your branches.
17 
+In this section, you run tests in the `dry-run-test` branch of your Docker
18 
+fork. If you have followed along in this guide, you already have this branch.
19 
+If you don't have this branch, you can create it or simply use another of your
20 
+branches.
15 21
16 22 
 ## Understand testing at Docker
17 23
... ... 
@@ -23,51 +36,59 @@ href="http://golang.org/pkg/testing/" target="_blank">Go's testing package
23 23 
 documentation</a> and the <a href="http://golang.org/cmd/go/#hdr-Test_packages"
24 24 
 target="_blank">go test help</a>.
25 25
26 
-You are responsible for _unit testing_ your contribution when you add new or change existing Docker code. A unit test is a piece of code that invokes a single, small piece of code ( _unit of work_ ) to verify the unit works as expected.
26 
+You are responsible for _unit testing_ your contribution when you add new or
27 
+change existing Docker code. A unit test is a piece of code that invokes a
28 
+single, small piece of code ( _unit of work_ ) to verify the unit works as
29 
+expected.
27 30
28 
-Depending on your contribution, you may need to add _integration tests_. These are tests that combine two or more work units into one component. These work units each have unit tests and then, together, integration tests that test the interface between the components. The `integration` and `integration-cli` directories in the Docker repository contain integration test code.
31 
+Depending on your contribution, you may need to add _integration tests_. These
32 
+are tests that combine two or more work units into one component. These work
33 
+units each have unit tests and then, together, integration tests that test the
34 
+interface between the components. The `integration` and `integration-cli`
35 
+directories in the Docker repository contain integration test code.
29 36
30 
-Testing is its own speciality. If you aren't familiar with testing techniques, there is a lot of information available to you on the Web. For now, you should understand that, the Docker maintainers may ask you to write a new test or change an existing one.
37 
+Testing is its own speciality. If you aren't familiar with testing techniques,
38 
+there is a lot of information available to you on the Web. For now, you should
39 
+understand that, the Docker maintainers may ask you to write a new test or
40 
+change an existing one.
31 41
32 42 
 ### Run tests on your local host
33 43
34 
-Before submitting any code change, you should run the entire Docker test suite. The `Makefile` contains a target for the entire test suite. The target's name is simply `test`. The make file contains several targets for testing:
44 
+Before submitting any code change, you should run the entire Docker test suite.
45 
+The `Makefile` contains a target for the entire test suite. The target's name
46 
+is simply `test`. The make file contains several targets for testing:
35 47
36 48 
 <style type="text/css">
37 
-.tg  {border-collapse:collapse;border-spacing:0;margin-bottom:15px;}
38 
-.tg td{font-family:Arial, sans-serif;font-size:14px;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
39 
-.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;text-align:left;}
40 
-.tg .tg-vyw9{font-family:"Courier New", Courier, monospace !important;}
41 
-.tg .tg-e3zv{font-weight:bold}
49 
+.make-target {font-family:"Courier New", Courier, monospace !important;}
42 50 
 </style>
43 51 
 <table class="tg">
44 52 
   <tr>
45 
-    <th class="tg-e3zv">Target</th>
46 
-    <th class="tg-e3zv">What this target does</th>
53 
+    <th>Target</th>
54 
+    <th>What this target does</th>
47 55 
   </tr>
48 56 
   <tr>
49 
-    <td class="tg-vyw9">test</td>
50 
-    <td class="tg-031e">Run all the tests.</td>
57 
+    <td class="make-target">test</td>
58 
+    <td>Run all the tests.</td>
51 59 
   </tr>
52 60 
   <tr>
53 
-    <td class="tg-vyw9">test-unit</td>
54 
-    <td class="tg-031e">Run just the unit tests.</td>
61 
+    <td class="make-target">test-unit</td>
62 
+    <td>Run just the unit tests.</td>
55 63 
   </tr>
56 64 
   <tr>
57 
-    <td class="tg-vyw9">test-integration</td>
58 
-    <td class="tg-031e">Run just integration tests.</td>
65 
+    <td class="make-target">test-integration</td>
66 
+    <td>Run just integration tests.</td>
59 67 
   </tr>
60 68 
   <tr>
61 
-    <td class="tg-vyw9">test-integration-cli</td>
62 
-    <td class="tg-031e">Run the test for the integration command line interface.</td>
69 
+    <td class="make-target">test-integration-cli</td>
70 
+    <td>Run the test for the integration command line interface.</td>
63 71 
   </tr>
64 72 
   <tr>
65 
-    <td class="tg-vyw9">test-docker-py</td>
66 
-    <td class="tg-031e">Run the tests for Docker API client.</td>
73 
+    <td class="make-target">test-docker-py</td>
74 
+    <td>Run the tests for Docker API client.</td>
67 75 
   </tr>
68 76 
   <tr>
69 
-    <td class="tg-vyw9">docs-test</td>
70 
-    <td class="tg-031e">Runs the documentation test build.</td>
77 
+    <td class="make-target">docs-test</td>
78 
+    <td>Runs the documentation test build.</td>
71 79 
   </tr>
72 80 
 </table>
73 81
... ... 
@@ -77,40 +98,44 @@ Run the entire test suite on your current repository:
77 77
78 78 
 2. Change to the root your Docker repository.
79 79
80 
-		$ cd docker-fork
80 
+        $ cd docker-fork
81 81
82 82 
 3. Make sure you are in your development branch.
83 83
84 
-		$ git checkout dry-run-test
84 
+        $ git checkout dry-run-test
85 85
86 86 
 4. Run the `make test` command.
87 87
88 
-		$ make test
89 
-
90 
-	This command does several things, it creates a container temporarily for testing. Inside that container, the `make`:
91 
-
92 
-	* creates a new binary
93 
-	* cross-compiles all the binaries for the various operating systems
94 
-	* runs the all the tests in the system
95 
-
96 
-	It can take several minutes to run all the tests. When they complete
97 
-	successfully, you see the output concludes with something like this:
98 
-
99 
-
100 
-		[PASSED]: top - sleep process should be listed in privileged mode
101 
-		[PASSED]: version - verify that it works and that the output is properly formatted
102 
-		PASS
103 
-		coverage: 70.8% of statements
104 
-		---> Making bundle: test-docker-py (in bundles/1.5.0-dev/test-docker-py)
105 
-		+++ exec docker --daemon --debug --host unix:///go/src/github.com/docker/docker/bundles/1.5.0-dev/test-docker-py/docker.sock --storage-driver vfs --exec-driver native --pidfile /go/src/github.com/docker/docker/bundles/1.5.0-dev/test-docker-py/docker.pid
106 
-		.................................................................
107 
-		----------------------------------------------------------------------
108 
-		Ran 65 tests in 89.266s
109 
-
110 
-
88 
+        $ make test
89 
+
90 
+    This command does several things, it creates a container temporarily for
91 
+    testing. Inside that container, the `make`:
92 
+
93 
+    * creates a new binary
94 
+    * cross-compiles all the binaries for the various operating systems
95 
+    * runs the all the tests in the system
96 
+
97 
+    It can take several minutes to run all the tests. When they complete
98 
+    successfully, you see the output concludes with something like this:
99 
+
100 
+
101 
+        [PASSED]: top - sleep process should be listed in privileged mode
102 
+        [PASSED]: version - verify that it works and that the output is properly formatted
103 
+        PASS
104 
+        coverage: 70.8% of statements
105 
+        ---> Making bundle: test-docker-py (in bundles/1.5.0-dev/test-docker-py)
106 
+        +++ exec docker --daemon --debug --host unix:///go/src/github.com/docker/docker/bundles/1.5.0-dev/test-docker-py/docker.sock --storage-driver vfs --exec-driver native --pidfile /go/src/github.com/docker/docker/bundles/1.5.0-dev/test-docker-py/docker.pid
107 
+        .................................................................
108 
+        ----------------------------------------------------------------------
109 
+        Ran 65 tests in 89.266s
110 
+
111 
+
111 112 
 ### Run test targets inside the development container
112 113
113 
-If you are working inside a Docker development container, you use the `project/make.sh` script to run tests. The `project/make.sh` script doesn't have a single target that runs all the tests. Instead, you provide a single commmand line with multiple targets that does the same thing.
114 
+If you are working inside a Docker development container, you use the
115 
+`project/make.sh` script to run tests. The `project/make.sh` script doesn't
116 
+have a single target that runs all the tests. Instead, you provide a single
117 
+commmand line with multiple targets that does the same thing.
114 118
115 119 
 Try this now.
116 120
... ... 
@@ -118,38 +143,50 @@ Try this now.
118 118
119 119 
 2. Start a Docker development image.
120 120
121 
-	If you are following along with this guide, you should have a `dry-run-test` image.
121 
+    If you are following along with this guide, you should have a
122 
+    `dry-run-test` image.
122 123
123 
-		$ docker run --privileged --rm -ti -v `pwd`:/go/src/github.com/docker/docker dry-run-test /bin/bash
124 
+        $ docker run --privileged --rm -ti -v `pwd`:/go/src/github.com/docker/docker dry-run-test /bin/bash
124 125
125 126 
 3. Run the tests using the `project/make.sh` script.
126 127
127 
-		root@5f8630b873fe:/go/src/github.com/docker/docker# project/make.sh dynbinary binary cross test-unit test-integration test-integration-cli test-docker-py
128 
-
129 
-	The tests run just as they did within your local host.
130 
-
131 
-Of course, you can also run a subset of these targets too. For example, to run just the unit tests:
128 
+        root@5f8630b873fe:/go/src/github.com/docker/docker# project/make.sh dynbinary binary cross test-unit test-integration test-integration-cli test-docker-py
129 
+
130 
+    The tests run just as they did within your local host.
131 
+
132 132
133 
-			root@5f8630b873fe:/go/src/github.com/docker/docker# project/make.sh dynbinary binary cross test-unit
133 
+Of course, you can also run a subset of these targets too. For example, to run
134 
+just the unit tests:
134 135
135 
-Most test targets require that you build these precursor targets first: `dynbinary binary cross`
136 
+    root@5f8630b873fe:/go/src/github.com/docker/docker# project/make.sh dynbinary binary cross test-unit
137 
+
138 
+Most test targets require that you build these precursor targets first:
139 
+`dynbinary binary cross`
136 140
137 141
138 142 
 ## Running individual or multiple named tests
139 143
140 
-You can use the `TESTFLAGS` environment variable to run a single test. The flag's value is passed as arguments to the `go test` command. For example, from your local host you can run the `TestBuild` test with this command:
144 
+You can use the `TESTFLAGS` environment variable to run a single test. The
145 
+flag's value is passed as arguments to the `go test` command. For example, from
146 
+your local host you can run the `TestBuild` test with this command:
147 
+
148 
+        $ TESTFLAGS='-test.run \^TestBuild\$' make test
141 149
142 
-    	$ TESTFLAGS='-test.run \^TestBuild\$' make test
143 
-
144 150 
 To run the same test inside your Docker development container, you do this:
145 151
146 
-		root@5f8630b873fe:/go/src/github.com/docker/docker# TESTFLAGS='-run ^TestBuild$' project/make.sh
152 
+        root@5f8630b873fe:/go/src/github.com/docker/docker# TESTFLAGS='-run ^TestBuild$' project/make.sh
147 153
148 154 
 ## If test under Boot2Docker fail do to space errors
149 155
150 
-Running the tests requires about 2GB of memory. If you are running your container on bare metal, that is you are not running with Boot2Docker, your Docker development container is able to take the memory it requires directly from your local host.
156 
+Running the tests requires about 2GB of memory. If you are running your
157 
+container on bare metal, that is you are not running with Boot2Docker, your
158 
+Docker development container is able to take the memory it requires directly
159 
+from your local host.
151 160
152 
-If you are running Docker using Boot2Docker, the VM uses 2048MB by default. This means you can exceed the memory of your VM running tests in a Boot2Docker environment. When the test suite runs out of memory, it returns errors similar to the following:
161 
+If you are running Docker using Boot2Docker, the VM uses 2048MB by default.
162 
+This means you can exceed the memory of your VM running tests in a Boot2Docker
163 
+environment. When the test suite runs out of memory, it returns errors similar
164 
+to the following:
153 165
154 166 
     server.go:1302 Error: Insertion failed because database is full: database or
155 167 
     disk is full
... ... 
@@ -157,43 +194,44 @@ If you are running Docker using Boot2Docker, the VM uses 2048MB by default. This
157 157 
     utils_test.go:179: Error copy: exit status 1 (cp: writing
158 158 
     '/tmp/docker-testd5c9-[...]': No space left on device
159 159
160 
-To increase the memory on your VM, you need to reinitialize the Boot2Docker VM with new memory settings.
160 
+To increase the memory on your VM, you need to reinitialize the Boot2Docker VM
161 
+with new memory settings.
161 162
162 163 
 1. Stop all running containers.
163 164
164 165 
 2. View the current memory setting.
165 166
166 
-		$ boot2docker info
167 
-		{
168 
-			"Name": "boot2docker-vm",
169 
-			"UUID": "491736fd-4075-4be7-a6f5-1d4cdcf2cc74",
170 
-			"Iso": "/Users/mary/.boot2docker/boot2docker.iso",
171 
-			"State": "running",
172 
-			"CPUs": 8,
173 
-			"Memory": 2048,
174 
-			"VRAM": 8,
175 
-			"CfgFile": "/Users/mary/VirtualBox VMs/boot2docker-vm/boot2docker-vm.vbox",
176 
-			"BaseFolder": "/Users/mary/VirtualBox VMs/boot2docker-vm",
177 
-			"OSType": "",
178 
-			"Flag": 0,
179 
-			"BootOrder": null,
180 
-			"DockerPort": 0,
181 
-			"SSHPort": 2022,
182 
-			"SerialFile": "/Users/mary/.boot2docker/boot2docker-vm.sock"
183 
-		}
167 
+        $ boot2docker info
168 
+        {
169 
+            "Name": "boot2docker-vm",
170 
+            "UUID": "491736fd-4075-4be7-a6f5-1d4cdcf2cc74",
171 
+            "Iso": "/Users/mary/.boot2docker/boot2docker.iso",
172 
+            "State": "running",
173 
+            "CPUs": 8,
174 
+            "Memory": 2048,
175 
+            "VRAM": 8,
176 
+            "CfgFile": "/Users/mary/VirtualBox VMs/boot2docker-vm/boot2docker-vm.vbox",
177 
+            "BaseFolder": "/Users/mary/VirtualBox VMs/boot2docker-vm",
178 
+            "OSType": "",
179 
+            "Flag": 0,
180 
+            "BootOrder": null,
181 
+            "DockerPort": 0,
182 
+            "SSHPort": 2022,
183 
+            "SerialFile": "/Users/mary/.boot2docker/boot2docker-vm.sock"
184 
+        }
184 185
185 186
186 187 
 3. Delete your existing `boot2docker` profile.
187 188
188 
-		$ boot2docker delete
189 
+        $ boot2docker delete
189 190
190 191 
 4. Reinitialize `boot2docker` and specify a higher memory.
191 192
192 
-		$ boot2docker init -m 5555
193 
+        $ boot2docker init -m 5555
193 194
194 195 
 5. Verify the memory was reset.
195 196
196 
-		$ boot2docker info
197 
+        $ boot2docker info
197 198
198 199 
 6. Restart your container and try your test again.
199 200
... ... 
@@ -206,43 +244,49 @@ href="http://www.mkdocs.org/" target="_blank">MkDocs</a> to build Docker's
206 206 
 documentation. Of course, you don't need to install this generator
207 207 
 to build the documentation, it is included with container.
208 208
209 
-You should always check your documentation for grammar and spelling. The best way to do this is with <a href="http://www.hemingwayapp.com/" target="_blank">an online grammar checker</a>.
209 
+You should always check your documentation for grammar and spelling. The best
210 
+way to do this is with <a href="http://www.hemingwayapp.com/"
211 
+target="_blank">an online grammar checker</a>.
210 212
211 
-When you change a documentation source file, you should test your change locally to make sure your content is there and any links work correctly. You can build the documentation from the local host.  The build starts a container and loads the documentation into a server. As long as this container runs, you can browse the docs.
213 
+When you change a documentation source file, you should test your change
214 
+locally to make sure your content is there and any links work correctly. You
215 
+can build the documentation from the local host. The build starts a container
216 
+and loads the documentation into a server. As long as this container runs, you
217 
+can browse the docs.
212 218
213 219 
 1. In a terminal, change to the root of your `docker-fork` repository.
214 220
215 
-		$ cd ~/repos/dry-run-test
221 
+        $ cd ~/repos/dry-run-test
216 222
217 223 
 2. Make sure you are in your feature branch.
218 224
219 
-		$ git status
220 
-		On branch dry-run-test
221 
-		Your branch is up-to-date with 'origin/dry-run-test'.
222 
-		nothing to commit, working directory clean
223 
-
225 
+        $ git status
226 
+        On branch dry-run-test
227 
+        Your branch is up-to-date with 'origin/dry-run-test'.
228 
+        nothing to commit, working directory clean
229 
+
224 230 
 3. Build the documentation.
225 231
226 
-		$ make docs
227 
-
228 
-	When the build completes, you'll see a final output message similar to the
229 
-	following:
230 
-
231 
-		Successfully built ee7fe7553123
232 
-		docker run --rm -it  -e AWS_S3_BUCKET -e NOCACHE -p 8000:8000 "docker-docs:dry-run-test" mkdocs serve
233 
-		Running at: http://0.0.0.0:8000/
234 
-		Live reload enabled.
235 
-		Hold ctrl+c to quit.
236 
-
232 
+        $ make docs
233 
+
234 
+    When the build completes, you'll see a final output message similar to the
235 
+    following:
236 
+
237 
+        Successfully built ee7fe7553123
238 
+        docker run --rm -it  -e AWS_S3_BUCKET -e NOCACHE -p 8000:8000 "docker-docs:dry-run-test" mkdocs serve
239 
+        Running at: http://0.0.0.0:8000/
240 
+        Live reload enabled.
241 
+        Hold ctrl+c to quit.
242 
+
237 243 
 4. Enter the URL in your browser.
238 244
239 
-	If you are running Boot2Docker, replace the default localhost address
240 
-	(0.0.0.0) with your DOCKERHOST value. You can get this value at any time by
241 
-	entering `boot2docker ip` at the command line.
242 
-
245 
+    If you are running Boot2Docker, replace the default localhost address
246 
+    (0.0.0.0) with your DOCKERHOST value. You can get this value at any time by
247 
+    entering `boot2docker ip` at the command line.
248 
+
243 249 
 5. Once in the documentation, look for the red notice to verify you are seeing the correct build.
244 250
245 
-	![Beta documentation](/project/images/red_notice.png)
251 
+    ![Beta documentation](/project/images/red_notice.png)
246 252
247 253 
 6. Navigate to your new or changed document.
248 254
... ... 
@@ -253,10 +297,7 @@ When you change a documentation source file, you should test your change locally
253 253
254 254 
 ## Where to go next
255 255
256 
-Congratulations, you have successfully completed the basics you need to understand the Docker test framework. In the next steps, you use what you have learned so far to [contribute to Docker by working on an issue](/project/make-a-contribution/).
257 
-
258 
-
259 
-
260 
-
261 
-
262 
-
256 
+Congratulations, you have successfully completed the basics you need to
257 
+understand the Docker test framework. In the next steps, you use what you have
258 
+learned so far to [contribute to Docker by working on an
259 
+issue](/project/make-a-contribution/).
docs/sources/project/who-written-for.md
History View file @ efc625f
... ... 
@@ -6,17 +6,31 @@ page_keywords: Gordon, introduction, turtle, machine, libcontainer, how to
6 6
7 7 
 This section of the documentation contains a guide for Docker users who want to
8 8 
 contribute code or documentation to the Docker project. As a community, we
9 
-share rules of behavior and interaction. Make sure you are familiar with the <a href="https://github.com/docker/docker/blob/master/CONTRIBUTING.md#docker-community-guidelines" target="_blank">community guidelines</a> before continuing.
9 
+share rules of behavior and interaction. Make sure you are familiar with the <a
10 
+href="https://github.com/docker/docker/blob/master/CONTRIBUTING.md#docker-community-guidelines"
11 
+target="_blank">community guidelines</a> before continuing.
10 12
11 13 
 ## Where and what you can contribute
12 14
13 
-The Docker project consists of not just one but several repositories on GitHub. So, in addition to the `docker/docker` repository, there is the `docker/libcontainer` repo, the `docker/machine` repo, and several more. Contribute to any of these and you contribute to the Docker project.
15 
+The Docker project consists of not just one but several repositories on GitHub.
16 
+So, in addition to the `docker/docker` repository, there is the
17 
+`docker/libcontainer` repo, the `docker/machine` repo, and several more.
18 
+Contribute to any of these and you contribute to the Docker project.
14 19
15 
-Not all Docker repositories use the Go language. Also, each repository has its own focus area. So, if you are an experienced contributor, think about contributing to a Docker repository that has a language or a focus area you are familiar with.
20 
+Not all Docker repositories use the Go language. Also, each repository has its
21 
+own focus area. So, if you are an experienced contributor, think about
22 
+contributing to a Docker repository that has a language or a focus area you are
23 
+familiar with.
16 24
17 
-If you are new to the open source community, to Docker, or to formal programming, you should start out contributing to the `docker/docker` repository. Why? Because this guide is written for that repository specifically.
25 
+If you are new to the open source community, to Docker, or to formal
26 
+programming, you should start out contributing to the `docker/docker`
27 
+repository. Why? Because this guide is written for that repository specifically.
18 28
19 
-Finally, code or documentation isn't the only way to contribute. You can report an issue, add to discussions in our community channel, write a blog post, or take a usability test. You can even propose your own type of contribution. Right now we don't have a lot written about this yet, so just email <mailto:feedback@docker.com> if this type of contributing interests you.
29 
+Finally, code or documentation isn't the only way to contribute. You can report
30 
+an issue, add to discussions in our community channel, write a blog post, or
31 
+take a usability test. You can even propose your own type of contribution.
32 
+Right now we don't have a lot written about this yet, so just email
33 
+<mailto:feedback@docker.com> if this type of contributing interests you.
20 34
21 35 
 ## A turtle is involved
22 36
... ... 
@@ -26,12 +40,18 @@ Enough said.
26 26
27 27 
 ## How to use this guide
28 28
29 
-This is written for the distracted, the overworked, the sloppy reader with fair `git` skills and a failing memory for the GitHub GUI. The guide attempts to explain how to use the Docker environment as precisely, predictably, and procedurally as possible.
29 
+This is written for the distracted, the overworked, the sloppy reader with fair
30 
+`git` skills and a failing memory for the GitHub GUI. The guide attempts to
31 
+explain how to use the Docker environment as precisely, predictably, and
32 
+procedurally as possible.
30 33
31 
-Users who are new to the Docker development environment should start by setting up their environment. Then, they should try a simple code change. After that, you should find something to work on or propose at totally new change.
34 
+Users who are new to the Docker development environment should start by setting
35 
+up their environment. Then, they should try a simple code change. After that,
36 
+you should find something to work on or propose at totally new change.
32 37
33 
-If you are a programming prodigy, you still may find this documentation useful. Please feel free to skim past information you find obvious or boring.
38 
+If you are a programming prodigy, you still may find this documentation useful.
39 
+Please feel free to skim past information you find obvious or boring.
34 40
35 41 
 ## How to get started
36 42
37 
-Start by [setting up the prerequisites for contributing](/project/set-up-prereqs/).
38 43 
\ No newline at end of file
44 
+Start by [setting up the prerequisites for contributing](/project/set-up-prereqs/).