Update the documentation

[jcfreeman2]

Most of my comments here are based on my experience using the documentation to cut a new release (dunedaq-v2.7.0). However, some are a bit more general. Starting from the main page...

https://dune-daq-sw.readthedocs.io/en/latest/packages/daq-release/:

• Do we still need the "How to use standalone release tarballs"?
• It would be nice to link to the "Nightly releases" page, though that page contains info of interest both to users and developers so it's not clear where to put the link
• Couple of typos - "Integraion", "coordiantion"

https://dune-daq-sw.readthedocs.io/en/latest/packages/daq-release/create_release/:

• I like the numbered-list approach to things. However, it seems like rather than being presented as asides, it would be nice to give the building of external packages its own entry (2), as well as the addition of Python modules (3).
• A subtle point, but the word "optional" is used in places where "if needed" would be more accurate. E.g., the addition of Python modules "if needed"
• In the section on the release script (7, as it currently stands), it should be mentioned that we'd want to bump the hardwired release version in it (e.g., from release_name="dunedaq-v2.7.0" to release_name="dunedaq-v2.8.0". Also it would be nice to give an example of how it would be called from the command line
• "publish the DAQ packages into cvmfs" probably deserves its own numbered item

https://dune-daq-sw.readthedocs.io/en/latest/packages/daq-release/make_ups_products/:

• Looks good, though I'll confess I haven't tried the "Step-by-step instructions" section

https://dune-daq-sw.readthedocs.io/en/latest/packages/daq-release/add_modules_to_pypi_repo/:

• It should be explained that before running pip2pi the user will need to open the cvmfs transaction in order for write permission to be permitted (see conversation from 11:45 AM Chicago time on August 12 on the software coordinator's Slack channel)
• It might be nice to mention what $PATH_TO_PYPI_REPO will typically be (i.e. /cvmfs/dunedaq.opensciencegrid.org/pypi-repo)
• It also might be nice to mention the use cases for when a user would want to follow "Prepare the repo in staging area on docker-bd" and "Publishing to cvmfs repo". Plus it wouldn't hurt to spell out docker-bd as docker-bd.fnal.gov

https://dune-daq-sw.readthedocs.io/en/latest/packages/daq-release/ci_github_action/:

• Some of the times need to be updated (e.g. we don't build at 2 AM anymore)
• It might be possible to do a better job moving the sections of interest to users (like the link to the workflow status page) up to the top of the document

https://dune-daq-sw.readthedocs.io/en/latest/packages/daq-release/publish_to_cvmfs/:

• An explicit mention of a recommended gpvm node for staging wouldn't hurt
• Since "Other ways to publish files" is basically deprecated we should at least move it down to the bottom of the document
• Maybe it's just me, but path/to/delete sounds exclusively like directories even though a file can have a path. qualified/path/of/file/or/directory?
• For deletion via cvmfs_server ingest, make the point that the filename should be given relative to /cvmfs/dunedaq.opensciencegrid.org (or I suppose /cvmfs/dunedaq-development.opensciencegrid.org, depending on the scenario)

[dingp]

Many of the UPS-related pages should be removed since we moved to space-based release.

Release building and PyPI repo preparations have been automated by GitHub Actions, so those pages may be removed too, but information on how they are setup and run should be added to the GitHub Actions documentation.

[dingp]

Closing the issue after updating docs and removing(unlinking obsolete pages).