discussion: Focus on change to user interface and documentation, avoiding change to class (refactoring) and serialization to minimize scope for upcoming release.
Jody Garnett
August 20, 2020 at 10:27 PM
Also note master password, change to root password (agrees with the description in the docs).
I was reminded of this section of the docs by a recent article with ZFS changing to the use of "dependents".
master/slave to master/replicant
There are some established guidelines here that may be considered for context.
Recommend use of "master" / "minion" terminology, where minion is a follower or subordinate.
Update: master/replicant used in the PR.
whitelist/blacklist to allowlist/blocklist
Recommend use of allow-list and block-list
master branch to main branch
Github publicly stated they plan to change "master" to a neutral term (example "main").
This has shown up in the most recent release of the git command line tool:
https://github.blog/2020-07-27-highlights-from-git-2-28/
`git config --global init.defaultBranch main`
Developer guide, release scripts, jenkins builds, PR checks, documentation redirects and links (in config.py).
The use of "master" in this context defined as:
> noun: an original movie, recording, or document from which copies can be made.
It looks like there will be some kind of seamless option to transition to a "main" branch later in the year.
Recommend waiting on forthcoming GitHub support for seamless transition to use of "main" branch
master password
Recommend use of "root" password.
Update use of keystore password decided in on PR review