Fix documentation links and flow

Signed-off-by: Chris Evich <cevich@redhat.com>

2 files changed, 50 insertions, 41 deletions

diff --git a/README.md b/README.md
index 640e298e4..865900c62 100644
--- a/README.md
+++ b/README.md
@@ -1,15 +1,15 @@
 ![PODMAN logo](logo/podman-logo-source.svg)
-# libpod - library for running OCI-based containers in Pods
 
-### Latest Version: 0.12.1
-### Status: Active Development
+# Library and tool for running OCI-based containers in Pods
 
-### Continuous Integration: [![Build Status](https://api.cirrus-ci.com/github/containers/libpod.svg)](https://cirrus-ci.com/github/containers/libpod)
+Libpod provides a library for applications looking to use the Container Pod concept,
+popularized by Kubernetes.  libpod also contains the `podman` tool, for managing
+Pods, Containers, and Container Images.
 
-## What is the scope of this project?
+* [Latest Version: 0.12.1](https://github.com/containers/libpod/releases/latest)
+* [Continuous Integration:](contrib/cirrus/README.md) [![Build Status](https://api.cirrus-ci.com/github/containers/libpod.svg)](https://cirrus-ci.com/github/containers/libpod/master)
 
-libpod provides a library for applications looking to use the Container Pod concept popularized by Kubernetes.
-libpod also contains a tool called podman for managing Pods, Containers, and Container Images.
+## Overview and scope
 
 At a high level, the scope of libpod and podman is the following:
 
@@ -19,11 +19,22 @@ At a high level, the scope of libpod and podman is the following:
 * Full management of container lifecycle
 * Support for pods to manage groups of containers together
 * Resource isolation of containers and pods.
+* Integration with CRI-O to share containers and backend code.
 
-## What is not in scope for this project?
+## Roadmap
 
-* Signing and pushing images to various image storages. See [Skopeo](https://github.com/containers/skopeo/).
-* Container Runtimes daemons for working with Kubernetes CRIs. See [CRI-O](https://github.com/kubernetes-sigs/cri-o). We are working to integrate libpod into CRI-O to share containers and backend code with Podman.
+1. Python frontend for Varlink API
+1. Integrate libpod into CRI-O to replace its existing container management backend
+1. Further work on the podman pod command
+1. Further improvements on rootless containers
+1. In-memory locking to replace file locks
+
+## Out of scope
+
+* Signing and pushing images to various image storages.
+  See [Skopeo](https://github.com/containers/skopeo/).
+* Container Runtimes daemons for working with Kubernetes CRIs.
+  See [CRI-O](https://github.com/kubernetes-sigs/cri-o).
 
 ## OCI Projects Plans
 
@@ -68,14 +79,6 @@ Release notes for recent Podman versions
 **[Contributing](CONTRIBUTING.md)**
 Information about contributing to this project.
 
-## Current Roadmap
-
-1. Python frontend for Varlink API
-1. Integrate libpod into CRI-O to replace its existing container management backend
-1. Further work on the podman pod command
-1. Further improvements on rootless containers
-1. In-memory locking to replace file locks
-
 [spec-hooks]: https://github.com/opencontainers/runtime-spec/blob/v2.0.1/config.md#posix-platform-hooks
 
 ## Buildah and Podman relationship
diff --git a/contrib/cirrus/README.md b/contrib/cirrus/README.md
index 436dc5257..e175479f1 100644
--- a/contrib/cirrus/README.md
+++ b/contrib/cirrus/README.md
@@ -66,6 +66,18 @@ task (pass or fail) is set based on the exit status of the last script to execut
 
 ### ``cache_images`` Task
 
+Modifying the contents of cache-images is done by making changes to
+one or more of the ``./contrib/cirrus/packer/*_setup.sh`` files.  Testing
+those changes currently requires adding a temporary commit to a PR that
+updates ``.cirrus.yml``:
+
+* Remove all task sections except ``cache_images_task``.
+* Remove the ``only_if`` condition and ``depends_on`` dependencies
+
+The new image names will be displayed at the end of output, assuming the build
+is successful, at that point the temporary commit may be removed.  Finally,
+the new names may be used as ``image_name`` values in ``.cirrus.yml``.
+
 ***N/B: Steps below are performed by automation***
 
 1. When a PR is merged (``$CIRRUS_BRANCH`` == ``master``), run another
@@ -90,12 +102,6 @@ task (pass or fail) is set based on the exit status of the last script to execut
     3. If successful, shut down each VM and create a new GCE Image
        named with the base image, and the commit sha of the merge.
 
-***Note:*** The ``.cirrus.yml`` file must be manually updated with the new
-images names, then the change sent in via a secondary pull-request.  This
-ensures that all the ``integration_testing`` tasks can pass with the new images,
-before subjecting all future PRs to them.  A workflow to automate this
-process is described in comments at the end of the ``.cirrus.yml`` file.
-
 ### Base-images
 
 Base-images are VM disk-images specially prepared for executing as GCE VMs.
@@ -120,27 +126,27 @@ as the standard 'cloud-init' services.
 To produce new base-images, including an `image-builder-image` (used by
 the ``cache_images`` Task) some input parameters are required:
 
-    *  ``GCP_PROJECT_ID``: The complete GCP project ID string e.g. foobar-12345
-       identifying where the images will be stored.
+* ``GCP_PROJECT_ID``: The complete GCP project ID string e.g. foobar-12345
+  identifying where the images will be stored.
 
-    *  ``GOOGLE_APPLICATION_CREDENTIALS``: A *JSON* file containing
-       credentials for a GCE service account.  This can be [a service
-       account](https://cloud.google.com/docs/authentication/production#obtaining_and_providing_service_account_credentials_manually)
-       or [end-user
-       credentials](https://cloud.google.com/docs/authentication/end-user#creating_your_client_credentials]
+* ``GOOGLE_APPLICATION_CREDENTIALS``: A *JSON* file containing
+  credentials for a GCE service account.  This can be [a service
+  account](https://cloud.google.com/docs/authentication/production#obtaining_and_providing_service_account_credentials_manually)
+  or [end-user
+  credentials](https://cloud.google.com/docs/authentication/end-user#creating_your_client_credentials)
 
-    *  ``RHEL_IMAGE_FILE`` and ``RHEL_CSUM_FILE`` complete paths
-       to a `rhel-server-ec2-*.raw.xz` and it's cooresponding
-       checksum file.  These must be supplied manually because
-       they're not available directly via URL like other images.
+* ``RHEL_IMAGE_FILE`` and ``RHEL_CSUM_FILE`` complete paths
+  to a `rhel-server-ec2-*.raw.xz` and it's cooresponding
+  checksum file.  These must be supplied manually because
+  they're not available directly via URL like other images.
 
-    * ``RHSM_COMMAND`` contains the complete string needed to register
-      the VM for installing package dependencies.  The VM will be de-registered
-      upon completion.
+* ``RHSM_COMMAND`` contains the complete string needed to register
+  the VM for installing package dependencies.  The VM will be de-registered
+  upon completion.
 
-    *  Optionally, CSV's may be specified to ``PACKER_BUILDS``
-       to limit the base-images produced.  For example,
-       ``PACKER_BUILDS=fedora,image-builder-image``.
+*  Optionally, CSV's may be specified to ``PACKER_BUILDS``
+   to limit the base-images produced.  For example,
+   ``PACKER_BUILDS=fedora,image-builder-image``.
 
 If there is an existing 'image-builder-image' within GCE, it may be utilized
 to produce base-images (in addition to cache-images).  However it must be