New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version 14.0 integration branch #57
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This adds measurements of various measurements of KPMs for the RC1 for V14.0. We could add a few more measurements (v13 included y-band). Also, some of the SRD numbers changed in this new report. Those should be checked. We should also define the canonical place to find the KPM performance ramp. I assume LDM-240 is no longer the place.
- Move links downwards to not distract from installation docs. - Separate "Installation" from "Project info" sections so that release notes and such don't distract from how-to pages for installing the stack.
This makes it easier to document pre-requisites from either the lsstsw or newinstall installation methods. Overall it makes the newinstall docs easier to follow, as well, making it possible to use the newinstall docs from a getting started context.
A conda distribution is no longer provided with v14 of the stack.
- Simplify the newinstall.sh installation instructions to minimize commentary in the how-to steps. The idea is that this commentary and alternative installation strategies will be linked to an "advanced topics" section. - Update the newinstall.sh command so it uses binaries (-t). Also use (-c) to continue a failed build because Josh Hoblitt recommends it. - Point to the 14.0 release. - Adds sections on binaries, ABI compatibility, tag format, the Miniconda Python, and background/reference on newinstall.sh itself.
This explains and mentions that lsst_apps and lsst_distrib both exist. The page will get better when we have packages in the pipelines.lsst.io docs and they automatically report their package dependencies.
This is a standalone from the installation instructions to make it easier to understanding what steps need to be done in in each new shell, compared to a new installation. Also lets us add additional background on `setup` itself.
This covers a basic quick start and how to find tags on Docker Hub. Future commits can add details on attaching volumes, developing against a containerized stack, and creating new images with Dockerfiles.
- Switch to sentence case headers. - Improve some of the technical writing style.
- Update for 14.0 - Move advanced how-to and reference material from the basic installation steps. - Add overviews of deploy and rebuild, along with command references.
The same docs should apply to all base installations, where it's newinstall, lsstsw, or Docker. This commit moves the original content to an orphan page to give us time to make that change.
Before, both the homepage and install/index.rst served as entrypoints for the installation docs. Now I'm making the homepage the curated documentation entrypoint, but install/index.rst has the toctree so that a user landing at https://pipelines.lsst.io/install can still find all the topics.
This wording encourages users to use the provided Python instead of using their own.
The versions here were migrated to DMTRs on Docushare to place them with other DM test reports.
There were no documentation improvements listed.
The Prerequisites page is likely the best page to state this information so that it can apply to both the newinstall.sh and lsstsw-based installation pathways. The reference platform statement is based on what we use at lsst-dev right now #55 (comment)
Both newinstall.sh and lsstsw-based installation pathways reference the same common topic on OS compatibility in the Prerequisites page.
- index - docker installation - lsstsw installation - set up topic - top-level package topic
We're seeing users struggle with knowing why binaries aren't being used. The goal of this topic is to give users some strategies for determining why they aren't getting binaries.
This covers the mechanics of setting up cloned packages and building them. It isn't intended to cover all development topics---just topics related to package installation.
This documents how to develop packages within docker containers. Includes section on mounting volumes and running containers in the background, as well, which are critical patterns for containerized development.
Eventually we should link to the "Getting started" tutorial series from here rather than only linking to more installation-related topics.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the integration PR for the v14.0 docs.
Online draft: https://pipelines.lsst.io/v/14-0
Included tickets:
/metrics.html
(@timj)Related release discussion: https://community.lsst.org/t/stack-release-14-0-status-and-discussion/2227