updates to devel/*.md files

docs/devel/adding-an-APIGroup.md

@@ -35,30 +35,55 @@ Documentation for other releases can be found at
 Adding an API Group
 ===============
 
-This document includes the steps to add an API group. You may also want to take a look at PR [#16621](https://github.com/kubernetes/kubernetes/pull/16621) and PR [#13146](https://github.com/kubernetes/kubernetes/pull/13146), which add API groups.
+This document includes the steps to add an API group. You may also want to take
+a look at PR [#16621](https://github.com/kubernetes/kubernetes/pull/16621) and
+PR [#13146](https://github.com/kubernetes/kubernetes/pull/13146), which add API
+groups.
 
-Please also read about [API conventions](api-conventions.md) and [API changes](api_changes.md) before adding an API group.
+Please also read about [API conventions](api-conventions.md) and
+[API changes](api_changes.md) before adding an API group.
 
 ### Your core group package:
 
-We plan on improving the way the types are factored in the future; see [#16062](https://github.com/kubernetes/kubernetes/pull/16062) for the directions in which this might evolve.
+We plan on improving the way the types are factored in the future; see
+[#16062](https://github.com/kubernetes/kubernetes/pull/16062) for the directions
+in which this might evolve.
 
-1. Create a folder in pkg/apis to hold you group. Create types.go in pkg/apis/`<group>`/ and pkg/apis/`<group>`/`<version>`/ to define API objects in your group;
+1. Create a folder in pkg/apis to hold you group. Create types.go in
+ pkg/apis/`<group>`/ and pkg/apis/`<group>`/`<version>`/ to define API objects
+ in your group;
 
-2. Create pkg/apis/`<group>`/{register.go, `<version>`/register.go} to register this group's API objects to the encoding/decoding scheme (e.g., [pkg/apis/extensions/register.go](../../pkg/apis/extensions/register.go) and [pkg/apis/extensions/v1beta1/register.go](../../pkg/apis/extensions/v1beta1/register.go);
+2. Create pkg/apis/`<group>`/{register.go, `<version>`/register.go} to register
+this group's API objects to the encoding/decoding scheme (e.g.,
+[pkg/apis/extensions/register.go](../../pkg/apis/extensions/register.go) and
+[pkg/apis/extensions/v1beta1/register.go](../../pkg/apis/extensions/v1beta1/register.go);
 
-3. Add a pkg/apis/`<group>`/install/install.go, which is responsible for adding the group to the `latest` package, so that other packages can access the group's meta through `latest.Group`. You probably only need to change the name of group and version in the [example](../../pkg/apis/extensions/install/install.go)). You need to import this `install` package in {pkg/master, pkg/client/unversioned}/import_known_versions.go, if you want to make your group accessible to other packages in the kube-apiserver binary, binaries that uses the client package.
+3. Add a pkg/apis/`<group>`/install/install.go, which is responsible for adding
+the group to the `latest` package, so that other packages can access the group's
+meta through `latest.Group`. You probably only need to change the name of group
+and version in the [example](../../pkg/apis/extensions/install/install.go)). You
+need to import this `install` package in {pkg/master,
+pkg/client/unversioned}/import_known_versions.go, if you want to make your group
+accessible to other packages in the kube-apiserver binary, binaries that uses
+the client package.
 
-Step 2 and 3 are mechanical, we plan on autogenerate these using the cmd/libs/go2idl/ tool.
+Step 2 and 3 are mechanical, we plan on autogenerate these using the
+cmd/libs/go2idl/ tool.
 
 ### Scripts changes and auto-generated code:
 
 1. Generate conversions and deep-copies:
 
-    1. Add your "group/" or "group/version" into hack/after-build/{update-generated-conversions.sh, update-generated-deep-copies.sh, verify-generated-conversions.sh, verify-generated-deep-copies.sh};
-    2. Make sure your pkg/apis/`<group>`/`<version>` directory has a doc.go file with the comment `// +genconversion=true`, to catch the attention of our gen-conversion script.
+    1. Add your "group/" or "group/version" into
+hack/after-build/{update-generated-conversions.sh,
+update-generated-deep-copies.sh, verify-generated-conversions.sh,
+verify-generated-deep-copies.sh};
+    2. Make sure your pkg/apis/`<group>`/`<version>` directory has a doc.go file
+with the comment `// +genconversion=true`, to catch the attention of our
+gen-conversion script.
     3. Run hack/update-all.sh.
 
+
 2. Generate files for Ugorji codec:
 
     1. Touch types.generated.go in pkg/apis/`<group>`{/, `<version>`};
@@ -66,19 +91,29 @@ Step 2 and 3 are mechanical, we plan on autogenerate these using the cmd/libs/go
 
 ### Client (optional):
 
-We are overhauling pkg/client, so this section might be outdated; see [#15730](https://github.com/kubernetes/kubernetes/pull/15730) for how the client package might evolve. Currently, to add your group to the client package, you need to
+We are overhauling pkg/client, so this section might be outdated; see
+[#15730](https://github.com/kubernetes/kubernetes/pull/15730) for how the client
+package might evolve. Currently, to add your group to the client package, you
+need to:
 
-1. Create pkg/client/unversioned/`<group>`.go, define a group client interface and implement the client. You can take pkg/client/unversioned/extensions.go as a reference.
+1. Create pkg/client/unversioned/`<group>`.go, define a group client interface
+and implement the client. You can take pkg/client/unversioned/extensions.go as a
+reference.
 
-2. Add the group client interface to the `Interface` in pkg/client/unversioned/client.go and add method to fetch the interface. Again, you can take how we add the Extensions group there as an example.
+2. Add the group client interface to the `Interface` in
+pkg/client/unversioned/client.go and add method to fetch the interface. Again,
+you can take how we add the Extensions group there as an example.
 
-3. If you need to support the group in kubectl, you'll also need to modify pkg/kubectl/cmd/util/factory.go.
+3. If you need to support the group in kubectl, you'll also need to modify
+pkg/kubectl/cmd/util/factory.go.
 
 ### Make the group/version selectable in unit tests (optional):
 
-1. Add your group in pkg/api/testapi/testapi.go, then you can access the group in tests through testapi.`<group>`;
+1. Add your group in pkg/api/testapi/testapi.go, then you can access the group
+in tests through testapi.`<group>`;
 
-2. Add your "group/version" to `KUBE_API_VERSIONS` and `KUBE_TEST_API_VERSIONS` in hack/test-go.sh.
+2. Add your "group/version" to `KUBE_API_VERSIONS` and `KUBE_TEST_API_VERSIONS`
+in hack/test-go.sh.
 
 TODO: Add a troubleshooting section.
 

docs/devel/automation.md

@@ -36,8 +36,9 @@ Documentation for other releases can be found at
 
 ## Overview
 
-Kubernetes uses a variety of automated tools in an attempt to relieve developers of repetitive, low
-brain power work.  This document attempts to describe these processes.
+Kubernetes uses a variety of automated tools in an attempt to relieve developers
+of repetitive, low brain power work. This document attempts to describe these
+processes.
 
 
 ## Submit Queue
@@ -47,8 +48,11 @@ In an effort to
    * maintain e2e stability
    * load test githubs label feature
 
-We have added an automated [submit-queue](https://github.com/kubernetes/contrib/blob/master/mungegithub/mungers/submit-queue.go) to the
-[github "munger"](https://github.com/kubernetes/contrib/tree/master/mungegithub) for kubernetes.
+We have added an automated [submit-queue]
+(https://github.com/kubernetes/contrib/blob/master/mungegithub/mungers/submit-queue.go)
+to the
+[github "munger"](https://github.com/kubernetes/contrib/tree/master/mungegithub)
+for kubernetes.
 
 The submit-queue does the following:
 
@@ -76,59 +80,76 @@ A PR is considered "ready for merging" if it matches the following:
       * it has passed the Jenkins e2e test
       * it has the `e2e-not-required` label
 
-Note that the combined whitelist/committer list is available at [submit-queue.k8s.io](http://submit-queue.k8s.io)
+Note that the combined whitelist/committer list is available at
+[submit-queue.k8s.io](http://submit-queue.k8s.io)
 
 ### Merge process
 
-Merges _only_ occur when the `critical builds` (Jenkins e2e for gce, gke, scalability, upgrade) are passing.
-We're open to including more builds here, let us know...
+Merges _only_ occur when the `critical builds` (Jenkins e2e for gce, gke,
+scalability, upgrade) are passing. We're open to including more builds here, let
+us know...
 
-Merges are serialized, so only a single PR is merged at a time, to ensure against races.
+Merges are serialized, so only a single PR is merged at a time, to ensure
+against races.
 
-If the PR has the `e2e-not-required` label, it is simply merged.
-If the PR does not have this label, e2e tests are re-run, if these new tests pass, the PR is merged.
+If the PR has the `e2e-not-required` label, it is simply merged. If the PR does
+not have this label, e2e tests are re-run, if these new tests pass, the PR is
+merged.
 
-If e2e flakes or is currently buggy, the PR will not be merged, but it will be re-run on the following
-pass.
+If e2e flakes or is currently buggy, the PR will not be merged, but it will be
+re-run on the following pass.
 
 ## Github Munger
 
-We also run a [github "munger"](https://github.com/kubernetes/contrib/tree/master/mungegithub)
+We also run a [github "munger."]
+(https://github.com/kubernetes/contrib/tree/master/mungegithub)
 
-This runs repeatedly over github pulls and issues and runs modular "mungers" similar to "mungedocs"
+This runs repeatedly over github pulls and issues and runs modular "mungers"
+similar to "mungedocs."
 
 Currently this runs:
-   * blunderbuss - Tries to automatically find an owner for a PR without an owner, uses mapping file here:
+   * blunderbuss - Tries to automatically find an owner for a PR without an
+owner, uses mapping file here:
         https://github.com/kubernetes/contrib/blob/master/mungegithub/blunderbuss.yml
-   * needs-rebase - Adds `needs-rebase` to PRs that aren't currently mergeable, and removes it from those that are.
+   * needs-rebase - Adds `needs-rebase` to PRs that aren't currently mergeable,
+and removes it from those that are.
    * size - Adds `size/xs` - `size/xxl` labels to PRs
-   * ok-to-test - Adds the `ok-to-test` message to PRs that have an `lgtm` but the e2e-builder would otherwise not test due to whitelist
-   * ping-ci - Attempts to ping the ci systems (Travis) if they are missing from a PR.
-   * lgtm-after-commit - Removes the `lgtm` label from PRs where there are commits that are newer than the `lgtm` label
+   * ok-to-test - Adds the `ok-to-test` message to PRs that have an `lgtm` but
+the e2e-builder would otherwise not test due to whitelist
+   * ping-ci - Attempts to ping the ci systems (Travis) if they are missing from
+a PR.
+   * lgtm-after-commit - Removes the `lgtm` label from PRs where there are
+commits that are newer than the `lgtm` label
 
 In the works:
-   * issue-detector - machine learning for determining if an issue that has been filed is a `support` issue, `bug` or `feature`
+   * issue-detector - machine learning for determining if an issue that has been
+filed is a `support` issue, `bug` or `feature`
 
-Please feel free to unleash your creativity on this tool, send us new mungers that you think will help support the Kubernetes development process.
+Please feel free to unleash your creativity on this tool, send us new mungers
+that you think will help support the Kubernetes development process.
 
 ## PR builder
 
 We also run a robotic PR builder that attempts to run e2e tests for each PR.
 
-Before a PR from an unknown user is run, the PR builder bot (`k8s-bot`) asks to a message from a
-contributor that a PR is "ok to test", the contributor replies with that message.  Contributors can also
-add users to the whitelist by replying with the message "add to whitelist" ("please" is optional, but
-remember to treat your robots with kindness...)
+Before a PR from an unknown user is run, the PR builder bot (`k8s-bot`) asks to
+a message from a contributor that a PR is "ok to test", the contributor replies
+with that message. Contributors can also add users to the whitelist by replying
+with the message "add to whitelist" ("please" is optional, but remember to treat
+your robots with kindness...)
 
-If a PR is approved for testing, and tests either haven't run, or need to be re-run, you can ask the
-PR builder to re-run the tests.  To do this, reply to the PR with a message that begins with `@k8s-bot test this`, this should trigger a re-build/re-test.
+If a PR is approved for testing, and tests either haven't run, or need to be
+re-run, you can ask the PR builder to re-run the tests. To do this, reply to the
+PR with a message that begins with `@k8s-bot test this`, this should trigger a
+re-build/re-test.
 
 
 ## FAQ:
 
 #### How can I ask my PR to be tested again for Jenkins failures?
 
-Right now you have to ask a contributor (this may be you!) to re-run the test with "@k8s-bot test this"
+Right now you have to ask a contributor (this may be you!) to re-run the test
+with "@k8s-bot test this"
 
 ### How can I kick Travis to re-test on a failure?
 

docs/devel/cherry-picks.md

@@ -40,46 +40,54 @@ depending on the point in the release cycle.
 
 ## Propose a Cherry Pick
 
-1. Cherrypicks are [managed with labels and milestones](pull-requests.md#release-notes)
-1. All label/milestone accounting happens on PRs on master.  There's nothing to do on PRs targeted to the release branches.
-1. When you want a PR to be merged to the release branch, make the following label changes to the **master** branch PR:
+1. Cherrypicks are [managed with labels and milestones]
+(pull-requests.md#release-notes)
+1. All label/milestone accounting happens on PRs on master. There's nothing to
+do on PRs targeted to the release branches.
+1. When you want a PR to be merged to the release branch, make the following
+label changes to the **master** branch PR:
   * Remove release-note-label-needed
   * Add an appropriate release-note-(!label-needed) label
   * Add an appropriate milestone
   * Add the `cherrypick-candidate` label
   * The PR title is the **release note** you want published at release time and
-    note that PR titles are mutable and should reflect a release note
-    friendly message for any `release-note-*` labeled PRs.
+note that PR titles are mutable and should reflect a release note
+friendly message for any `release-note-*` labeled PRs.
 
 ### How do cherrypick-candidates make it to the release branch?
 
 1. **BATCHING:** After a branch is first created and before the X.Y.0 release
   * Branch owners review the list of `cherrypick-candidate` labeled PRs.
-  * PRs batched up and merged to the release branch get a `cherrypick-approved` label and lose the `cherrypick-candidate` label.
-  * PRs that won't be merged to the release branch, lose the `cherrypick-candidate` label.
+  * PRs batched up and merged to the release branch get a `cherrypick-approved`
+label and lose the `cherrypick-candidate` label.
+  * PRs that won't be merged to the release branch, lose the
+`cherrypick-candidate` label.
 
 1. **INDIVIDUAL CHERRYPICKS:** After the first X.Y.0 on a branch
-  * Run the cherry pick script.  This example applies a master branch PR #98765 to the remote branch `upstream/release-3.14`:
-    `hack/cherry_pick_pull.sh upstream/release-3.14 98765`
+  * Run the cherry pick script. This example applies a master branch PR #98765
+to the remote branch `upstream/release-3.14`:
+`hack/cherry_pick_pull.sh upstream/release-3.14 98765`
   * Your cherrypick PR (targeted to the branch) will immediately get the
-    `do-not-merge` label.  The branch owner will triage PRs targeted to
-    the branch and label the ones to be merged by applying the `lgtm`
-    label.
+`do-not-merge` label. The branch owner will triage PRs targeted to
+the branch and label the ones to be merged by applying the `lgtm`
+label.
 
-There is an [issue](https://github.com/kubernetes/kubernetes/issues/23347) open tracking the tool to automate the batching procedure.
+There is an [issue](https://github.com/kubernetes/kubernetes/issues/23347) open
+tracking the tool to automate the batching procedure.
 
 #### Cherrypicking a doc change
 
 If you are cherrypicking a change which adds a doc, then you also need to run
 `build/versionize-docs.sh` in the release branch to versionize that doc.
-Ideally, just running `hack/cherry_pick_pull.sh` should be enough, but we are not there
-yet: [#18861](https://github.com/kubernetes/kubernetes/issues/18861)
+Ideally, just running `hack/cherry_pick_pull.sh` should be enough, but we are
+not there yet: [#18861](https://github.com/kubernetes/kubernetes/issues/18861)
 
-To cherrypick PR 123456 to release-3.14, run the following commands after running `hack/cherry_pick_pull.sh` and before merging the PR:
+To cherrypick PR 123456 to release-3.14, run the following commands after
+running `hack/cherry_pick_pull.sh` and before merging the PR:
 
 ```
 $ git checkout -b automated-cherry-pick-of-#123456-upstream-release-3.14
-  origin/automated-cherry-pick-of-#123456-upstream-release-3.14
+origin/automated-cherry-pick-of-#123456-upstream-release-3.14
 $ ./build/versionize-docs.sh release-3.14
 $ git commit -a -m "Running versionize docs"
 $ git push origin automated-cherry-pick-of-#123456-upstream-release-3.14
@@ -97,9 +105,9 @@ requested - this should not be the norm, but it may happen.
 See the [cherrypick queue dashboard](http://cherrypick.k8s.io/#/queue) for
 status of PRs labeled as `cherrypick-candidate`.
 
-[Contributor License Agreements](http://releases.k8s.io/HEAD/CONTRIBUTING.md) is considered implicit
-for all code within cherry-pick pull requests, ***unless there is a large
-conflict***.
+[Contributor License Agreements](http://releases.k8s.io/HEAD/CONTRIBUTING.md) is
+considered implicit for all code within cherry-pick pull requests, ***unless
+there is a large conflict***.
 
 
 <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->

docs/devel/client-libraries.md

@@ -40,7 +40,8 @@ Documentation for other releases can be found at
 
 ### User Contributed
 
-*Note: Libraries provided by outside parties are supported by their authors, not the core Kubernetes team*
+*Note: Libraries provided by outside parties are supported by their authors, not
+the core Kubernetes team*
 
    * [Clojure](https://github.com/yanatan16/clj-kubernetes-api)
    * [Java (OSGi)](https://bitbucket.org/amdatulabs/amdatu-kubernetes)