FORMAT ALL THE THINGS

README-template.md

@@ -2,11 +2,7 @@
 
 %%TAGS%%
 
-For more information about this image and its history, please see the [relevant
-manifest file
-(`library/%%REPO%%`)](https://github.com/docker-library/official-images/blob/master/library/%%REPO%%)
-in the [`docker-library/official-images` GitHub
-repo](https://github.com/docker-library/official-images).
+For more information about this image and its history, please see the [relevant manifest file (`library/%%REPO%%`)](https://github.com/docker-library/official-images/blob/master/library/%%REPO%%) in the [`docker-library/official-images` GitHub repo](https://github.com/docker-library/official-images).
 
 %%CONTENT%%%%LICENSE%%
 

README.md

@@ -1,124 +1,91 @@
 # What is this?
 
-This repository contains the docs for each of the Docker official images.  See
-[docker-library/official-images](https://github.com/docker-library/official-images)
-for the configuration how the images are built.  To see all of the official
-images go to the
-[hub](https://registry.hub.docker.com/repos/stackbrew/?&s=alphabetical).
+This repository contains the docs for each of the Docker official images. See [docker-library/official-images](https://github.com/docker-library/official-images) for the configuration how the images are built. To see all of the official images go to the [hub](https://registry.hub.docker.com/repos/stackbrew/?&s=alphabetical).
 
 # How do I add a new image's docs
 
-- create a folder for my image: `mkdir myimage`
-- create a `README-short.txt` (required, 100 char max)
-- create a `content.md` (required, 80 col wrap)
-- create a `license.md` (required, 80 col wrap)
-- add a `logo.png` (recommended)
-- edit `update.sh` as needed (see below)
-- run `./update.sh myimage` to generate `myimage/README.md`
+-	create a folder for my image: `mkdir myimage`
+-	create a `README-short.txt` (required, 100 char max)
+-	create a `content.md` (required, 80 col wrap)
+-	create a `license.md` (required, 80 col wrap)
+-	add a `logo.png` (recommended)
+-	edit `update.sh` as needed (see below)
+-	run `./update.sh myimage` to generate `myimage/README.md`
 
 # What are all these files?
 
 ## `update.sh`
 
-This is the main script used to generate the `README.md` files for each image.
-The generated file is committed along with the files used to generate it (see
-below on what customizations are available).  When a new image is added that is
-not under the `docker-library` namespace on GitHub, a new entry must be added to
-the `otherRepos` array in this script.  Accepted arguments are which image(s)
-you want to update and no arguments to update all of them.
+This is the main script used to generate the `README.md` files for each image. The generated file is committed along with the files used to generate it (see below on what customizations are available). When a new image is added that is not under the `docker-library` namespace on GitHub, a new entry must be added to the `otherRepos` array in this script. Accepted arguments are which image(s) you want to update and no arguments to update all of them.
 
 ## `push.pl`
 
-This is used by us to push the actual content of the READMEs to the Docker Hub
-as special access is required to modify the Hub description contents.
+This is used by us to push the actual content of the READMEs to the Docker Hub as special access is required to modify the Hub description contents.
 
 ## `generate-dockerfile-links-partial.sh`
 
-This script is used by `update.sh` to create the "Supported tags and respective
-`Dockerfile` links" section of each generated `README.md` from the information
-in the [official-images `library/`
-manifests](https://github.com/docker-library/official-images/tree/master/library).
+This script is used by `update.sh` to create the "Supported tags and respective `Dockerfile` links" section of each generated `README.md` from the information in the [official-images `library/` manifests](https://github.com/docker-library/official-images/tree/master/library).
 
 ## `generate-repo-stub-readme.sh`
 
-This is used to generate a simple `README.md` to put in the image's repo.
-Argument is the name of the image, like `golang` and it then outputs the readme
-to standard out.
+This is used to generate a simple `README.md` to put in the image's repo. Argument is the name of the image, like `golang` and it then outputs the readme to standard out.
 
 ## `README-template.md` and `user-feedback.md`
 
-These files are the templates used in building the `<image name>/README.md`
-file, in combination with the individual image's files.
+These files are the templates used in building the `<image name>/README.md` file, in combination with the individual image's files.
 
 ## folder `<image name>`
 
-This is where all the partial and generated files for a given image reside, (ex:
-`golang/`).
+This is where all the partial and generated files for a given image reside, (ex: `golang/`).
 
 ## `<image name>/README.md`
 
 This file is generated using `update.sh`.
 
 ## `<image name>/content.md`
 
-This file contains the main content of your readme.  The basic parts you should
-have are a "What Is" section and a "How To" section.   See the doc on [Official
-Repos](https://docs.docker.com/docker-hub/official_repos/#a-long-description)
-for more information on long description.  The issues and contribution section
-is generated by the script but can be overridden.  The following is a basic
-layout:
-
-    # What is XYZ?
-
-    // about what the contained software is
-
-    %%LOGO%%
-
-    # How to use this image
-
-    // descriptions and examples of common use cases for the image
-    // make use of subsections as necessary
+This file contains the main content of your readme. The basic parts you should have are a "What Is" section and a "How To" section. See the doc on [Official Repos](https://docs.docker.com/docker-hub/official_repos/#a-long-description) for more information on long description. The issues and contribution section is generated by the script but can be overridden. The following is a basic layout:
+
+	# What is XYZ?
+
+	// about what the contained software is
+
+	%%LOGO%%
+
+	# How to use this image
+
+	// descriptions and examples of common use cases for the image
+	// make use of subsections as necessary
 
 ## `<image name>/README-short.txt`
 
-This is the short description for the docker hub, limited to 100 characters in a
-single line.
+This is the short description for the docker hub, limited to 100 characters in a single line.
 
 > Go (golang) is a general purpose, higher-level, imperative programming language.
 
 ## `<image name>/logo.png`
 
-Logo for the contained software.  Specifications can be found in the docs on
-[Official Repos](https://docs.docker.com/docker-hub/official_repos/#a-logo)
+Logo for the contained software. Specifications can be found in the docs on [Official Repos](https://docs.docker.com/docker-hub/official_repos/#a-logo)
 
 ## `<image name>/license.md`
 
-This file should contain a link to the license for the main software in the
-image, wrapped to 80 columns.  Here is an example for golang:
+This file should contain a link to the license for the main software in the image, wrapped to 80 columns. Here is an example for `golang`:
 
-    View [license information](http://golang.org/LICENSE)
-    for the software contained in this image.
+	View [license information](http://golang.org/LICENSE)
+	for the software contained in this image.
 
 ## `<image name>/user-feedback.md`
 
-This file is an optional override of the default `user-feedback.md` for those
-repositories with different issue and contributing policies.
+This file is an optional override of the default `user-feedback.md` for those repositories with different issue and contributing policies.
 
 ## `<image name>/mailing-list.md`
 
-This file is snippet that gets inserted into the user feedback section to
-provide and extra way to get help, like a mailing list.  Here is an example from
-the Postgres image:
+This file is snippet that gets inserted into the user feedback section to provide and extra way to get help, like a mailing list. Here is an example from the Postgres image:
 
-    on the [mailing list](http://www.postgresql.org/community/lists/subscribe/) or
+	on the [mailing list](http://www.postgresql.org/community/lists/subscribe/) or
 
 # Issues and Contributing
 
-If you would like to make a new Official Image, be sure to follow the
-[guidelines](https://docs.docker.com/docker-hub/official_repos/) and talk to
-[email protected].
+If you would like to make a new Official Image, be sure to follow the [guidelines](https://docs.docker.com/docker-hub/official_repos/) and talk to [email protected].
 
-Feel free to make a pull request for fixes and improvements to current
-documentation.  For questions or problems on this repo come talk to us via the
-`#docker-library` IRC channel on [Freenode](https://freenode.net) or open up an
-issue.
+Feel free to make a pull request for fixes and improvements to current documentation. For questions or problems on this repo come talk to us via the `#docker-library` IRC channel on [Freenode](https://freenode.net) or open up an issue.

buildpack-deps/content.md

@@ -1,11 +1,6 @@
 # What is `buildpack-deps`?
 
-In spirit, `buildpack-deps` is similar to [Heroku's stack
-images](https://github.com/heroku/stack-images/blob/master/bin/cedar.sh). It
-includes a large number of "development header" packages needed by various
-things like Ruby Gems, PyPI modules, etc. For example, `buildpack-deps` would
-let you do a `bundle install` in an arbitrary application directory without
-knowing beforehand that `ssl.h` is required to build a dependent module.
+In spirit, `buildpack-deps` is similar to [Heroku's stack images](https://github.com/heroku/stack-images/blob/master/bin/cedar.sh). It includes a large number of "development header" packages needed by various things like Ruby Gems, PyPI modules, etc. For example, `buildpack-deps` would let you do a `bundle install` in an arbitrary application directory without knowing beforehand that `ssl.h` is required to build a dependent module.
 
 %%LOGO%%
 
@@ -15,25 +10,14 @@ This stack is designed to be the foundation of a language-stack image.
 
 ## What's included?
 
-The main tags of this image are the full batteries-included approach.  With
-them, a majority of arbitrary `gem install` / `npm install` / `pip install`
-should be successfull without additional header/development packages.
+The main tags of this image are the full batteries-included approach. With them, a majority of arbitrary `gem install` / `npm install` / `pip install` should be successfull without additional header/development packages.
 
-For some language stacks, that doesn't make sense, particularly if linking to
-arbitrary external C libraries is much less common (as in Go and Java, for
-example), which is where these other smaller variants can come in handy.
+For some language stacks, that doesn't make sense, particularly if linking to arbitrary external C libraries is much less common (as in Go and Java, for example), which is where these other smaller variants can come in handy.
 
 ### `curl`
 
-This variant includes just the `curl`, `wget`, and `ca-certificates` packages.
-This is perfect for cases like the Java JRE, where downloading JARs is very
-common and necessary, but checking out code isn't.
+This variant includes just the `curl`, `wget`, and `ca-certificates` packages. This is perfect for cases like the Java JRE, where downloading JARs is very common and necessary, but checking out code isn't.
 
 ### `scm`
 
-This variant is based on `curl`, but also adds various source control management
-tools.  As of this writing, the current list of included tools is `bzr`, `git`,
-`hg`, and `svn`.  Intentionally missing is `cvs` due to the dwindling relevance
-it has (sorry CVS).  This image is perfect for cases like the Java JDK, where
-downloading JARs is very common (hence the `curl` base still), but checking out
-code also becomes more common as well (compared to the JRE).
+This variant is based on `curl`, but also adds various source control management tools. As of this writing, the current list of included tools is `bzr`, `git`, `hg`, and `svn`. Intentionally missing is `cvs` due to the dwindling relevance it has (sorry CVS). This image is perfect for cases like the Java JDK, where downloading JARs is very common (hence the `curl` base still), but checking out code also becomes more common as well (compared to the JRE).

buildpack-deps/license.md

@@ -1,2 +1 @@
-View [license information](https://www.debian.org/social_contract#guidelines)
-for the software contained in this image.
+View [license information](https://www.debian.org/social_contract#guidelines) for the software contained in this image.

busybox/content.md

@@ -1,15 +1,8 @@
 # What is BusyBox? The Swiss Army Knife of Embedded Linux
 
-At about 2.5 Mb in size, [BusyBox](http://www.busybox.net/) is a very good
-ingredient to craft space-efficient distributions.
+At about 2.5 Mb in size, [BusyBox](http://www.busybox.net/) is a very good ingredient to craft space-efficient distributions.
 
-BusyBox combines tiny versions of many common UNIX utilities into a single small
-executable. It provides replacements for most of the utilities you usually find
-in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer
-options than their full-featured GNU cousins; however, the options that are
-included provide the expected functionality and behave very much like their GNU
-counterparts. BusyBox provides a fairly complete environment for any small or
-embedded system.
+BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts. BusyBox provides a fairly complete environment for any small or embedded system.
 
 > [wikipedia.org/wiki/BusyBox](https://en.wikipedia.org/wiki/BusyBox)
 
@@ -19,31 +12,20 @@ embedded system.
 
 ## Run BusyBox shell
 
-    docker run -it --rm busybox
+	docker run -it --rm busybox
 
-This will drop you into an `sh` shell to allow you to do what you want inside a
-BusyBox system.
+This will drop you into an `sh` shell to allow you to do what you want inside a BusyBox system.
 
 ## Create a `Dockerfile` for a binary
 
-    FROM busybox
-    COPY ./my-static-binary /my-static-binary
-    CMD ["/my-static-binary"]
+	FROM busybox
+	COPY ./my-static-binary /my-static-binary
+	CMD ["/my-static-binary"]
 
-This `Dockerfile` will allow you to create a minimal image for your statically
-compiled binary.  You will have to compile the binary in some other place like
-another container.
+This `Dockerfile` will allow you to create a minimal image for your statically compiled binary. You will have to compile the binary in some other place like another container.
 
 ## More about this image
 
-The tags of this image are built using two different methods. The `ubuntu` tags
-are using the `busybox-static` package from Ubuntu, adding a few support files
-so that it works in Docker. It's super fast to build (a minute or even less).
-The `buildroot` tags are going the long way: they use buildroot to craft a whole
-filesystem, with busybox but also all required libraries and other support
-files. It has a stronger guarantee of "this will work". It is also smaller
-because it's using uclibc, however it takes hours to build.
-
-Having two totally different builders means that if one of the goes belly up, we
-can always fall-back on the other since this image is used in much of build
-testing of `docker` itself.
+The tags of this image are built using two different methods. The `ubuntu` tags are using the `busybox-static` package from Ubuntu, adding a few support files so that it works in Docker. It's super fast to build (a minute or even less). The `buildroot` tags are going the long way: they use buildroot to craft a whole filesystem, with busybox but also all required libraries and other support files. It has a stronger guarantee of "this will work". It is also smaller because it's using uclibc, however it takes hours to build.
+
+Having two totally different builders means that if one of the goes belly up, we can always fall-back on the other since this image is used in much of build testing of `docker` itself.

busybox/license.md

@@ -1,2 +1 @@
-View [license information](http://www.busybox.net/license.html)
-for the software contained in this image.
+View [license information](http://www.busybox.net/license.html) for the software contained in this image.