Dust off the README.md and pick some other nits

README.md

@@ -8,24 +8,24 @@ for those systems, and specified telemetry or data from various tools (`sar`,
 `vmstat`, `perf`, etc.).
 
 The second sub-system is the `pbench-server`, which is responsible for
-archiving result tar balls, indexing them, and unpacking them for display.
+archiving result tar balls, indexing them, and managing access to their
+contents.
+It provides a RESTful API which can be used by client applications, such as
+the Pbench Dashboard, which provides a web-based interface to the Pbench
+Server.
 
 The third sub-system is the `web-server` JS and CSS files, used to display
 various graphs and results, and any other content generated by the
 `pbench-agent` during benchmark and tool post-processing steps.
 
-The pbench Dashboard code lives in its own [repository](
-https://github.com/distributed-system-analysis/pbench-dashboard).
-
 ## How is it installed?
 Instructions on installing `pbench-agent`, can be found
 in the Pbench Agent [Getting Started Guide](
 https://distributed-system-analysis.github.io/pbench/gh-pages/start.html).
 
 For Fedora, CentOS, and RHEL users, we have made available [COPR
 builds](https://copr.fedorainfracloud.org/coprs/ndokos/pbench/) for the
-`pbench-agent`, `pbench-server`, `pbench-web-server`, and some benchmark and
-tool packages.
+`pbench-agent`, `pbench-web-server`, and some benchmark and tool packages.
 
 Install the `pbench-web-server` package on the machine from where you want to
 run the `pbench-agent` workloads, allowing you to view the graphs before
@@ -47,14 +47,11 @@ main documentation for a super quick set of introductory steps.
 The latest source code is at
 https://github.com/distributed-system-analysis/pbench.
 
-The pbench dashboard code is maintained separately at
-https://github.com/distributed-system-analysis/pbench-dashboard.
-
 ## Is there a mailing list for discussions?
 
 Yes, we use [Google Groups](https://groups.google.com/forum/#!forum/pbench)
 
-## How do I report and issue?
+## How do I report an issue?
 
 Please use GitHub's [issues](
 https://github.com/distributed-system-analysis/pbench/issues/new/choose).
@@ -66,7 +63,7 @@ https://github.com/distributed-system-analysis/pbench/projects).
 Please find projects covering the [Agent](
 https://github.com/distributed-system-analysis/pbench/projects/2),
 [Server](https://github.com/distributed-system-analysis/pbench/projects/3),
-[Dashboard]()https://github.com/distributed-system-analysis/pbench/projects/1,
+[Dashboard](https://github.com/distributed-system-analysis/pbench/projects/1),
 and a project that is named the same as the current [milestone](
 https://github.com/distributed-system-analysis/pbench/milestones).
 
@@ -75,7 +72,7 @@ https://github.com/distributed-system-analysis/pbench/milestones).
 Below are some simple steps for setting up a development environment for
 working with the Pbench code base.  For more detailed instructions on the
 workflow and process of contributing code to Pbench, refer to the [Guidelines
-for Contributing](docs/CONTRIBUTING.md).
+for Contributing](docs/Developers/contributing.md).
 
 ### Getting the Code
 
@@ -103,8 +100,6 @@ python using the python environment short-hands:
 
 See https://tox.wiki/en/latest/example/basic.html#a-simple-tox-ini-default-environments.
 
-Each time tests are run, the linting steps (`black` and `flake8`) are run first.
-
 You can provide arguments to the `tox` invocation to request sub-sets of the
 available tests be run.
 
@@ -132,12 +127,10 @@ Each of the "agent" and "server" tests can be further subsetted as follows:
 
   * server
     * python          -- runs the python tests (via python)
-    * legacy          -- runs the legacy tests
 
 For example:
 
   * `tox -- agent legacy`   -- run agent legacy tests
-  * `tox -- server legacy`  -- run server legacy tests
   * `tox -- server python`  -- run server python tests (via `pytest`)
 
 For any of the test sub-sets on either the agent or server sides of the tree,
@@ -146,7 +139,6 @@ allows one to request a specific test, or set of tests, or command line
 parameters to modify the test behavior:
 
   * `tox -- agent bench-scripts test-CL`    -- run bench-scripts' test-CL
-  * `tox -- server legacy test-28 test-32`  -- run server legacy tests 28 & 32
   * `tox -- server python -v`               -- run server python tests verbosely
 
 For the `agent/bench-scripts` tests, one can run entire sub-sets of tests using
@@ -158,18 +150,23 @@ a sub-directory name found in `agent/bench-scripts/tests`. For example:
 The first runs all the `pbench-fio` tests, while the second runs all the
 `pbench-uperf` and `pbench-linpack` tests.
 
+You can run the `build.sh` script to execute the linters, to run the unit tests
+for the Agent, Server, and Dashboard code, and to build installations for the
+Agent, Server, and Dashboard.
+
 Finally, see the `jenkins/Pipeline.gy` file for how the unit tests are run in
 our CI jobs.
 
 ### Python formatting
 
-This project uses the [flake8](http://flake8.pycqa.org/en/latest) method of code
+This project uses the [`flake8`](http://flake8.pycqa.org/en/latest) method of code
 style enforcement, linting, and checking.
 
 All python code contributed to pbench must match the style requirements. These
-requirements are enforced by the [pre-commit](https://pre-commit.com) hook
-using the [black](https://github.com/psf/black) Python code formatter and the
-[isort](https://github.com/pycqa/isort) Python import sorter.
+requirements are enforced by the [pre-commit](https://pre-commit.com) hook.  In
+addition to `flake8`, pbench uses the [`black`](https://github.com/psf/black)
+Python code formatter and the [`isort`](https://github.com/pycqa/isort) Python
+import sorter.
 
 ### Use pre-commit to set automatic commit requirements
 
@@ -194,14 +191,11 @@ starting with the `v0.70.0` release (`v<Major>.<Minor>.<Release>[-<Build>]`).
 Prior to the v0.70.0 release, the scheme used was mostly `v<Major>.<Minor>`,
 where we only had minor releases (`Major = 0`).
 
-The practice of using `-agent` or `-server` is also ending with the `v0.70.0`
-release.
-
 ### Container Image Tags
 This same GitHub "tag" scheme is used with tags applied to container images
 we build, with the following exceptions for tag names:
 
-  * `latest` - always points to the "latest" container image pushed to a
+  * `latest` - always points to the latest released container image pushed to a
     repository
 
   * `v<Major>-latest` - always points to the "latest" `Major` released
@@ -215,13 +209,9 @@ we build, with the following exceptions for tag names:
 ### References to Container Image Repositories
 The operation of our functional tests, the Pbench Server "in-a-can" used in
 the functional tests, and other verification and testing environments use
-container images from public repositories and non-public ones.  The CI jobs
+container images from remote image registries.  The CI jobs
 obtain references to those repositories using Jenkins credentials.  When a
-developer runs those same jobs locally, you can create two files with the
-appropriate contents locally:
-
-  * `${HOME}/.config/pbench/ci_registry.name`
-  * `${HOME}/.config/pbench/public_registry.name`
+running those same jobs locally, you can provide the registry via
+`${HOME}/.config/pbench/ci_registry.name`.
 
-If those files are not provided local execution will report an error when those
-values are missing.
+If this file is not provided, local execution will report an error.

docs/.gitignore

@@ -1 +1 @@
-_build/
+_build/

lib/pbench/agent/tool_data_sink.py

@@ -2125,7 +2125,7 @@ def start(prog: Path, parsed: Arguments):
 
 
 def main(argv: List[str]):
-    """Main program for the Tool Meister.
+    """Main program for the Tool Data Sink.
 
     Arguments:  argv - a list of parameters
 

lib/pbench/cli/agent/commands/triggers/register.py

@@ -107,7 +107,7 @@ def callback(ctxt, param, value):
     )(f)
 
 
-@click.command(help="list registered triggers")
+@click.command(help="register tool triggers")
 @common_options
 @_group_option
 @_start_option