port the rest of the scripts/docs over to the main branch

CHANGELOG.rst

@@ -4,4 +4,4 @@ Changelog
 
 The pytest CHANGELOG is located `here <https://docs.pytest.org/en/stable/changelog.html>`__.
 
-The source document can be found at: https://github.com/pytest-dev/pytest/blob/master/doc/en/changelog.rst
+The source document can be found at: https://github.com/pytest-dev/pytest/blob/main/doc/en/changelog.rst

CONTRIBUTING.rst

@@ -234,7 +234,7 @@ Here is a simple overview, with pytest-specific bits:
 
     $ git clone git@github.com:YOUR_GITHUB_USERNAME/pytest.git
     $ cd pytest
-    # now, create your own branch off "master":
+    # now, create your own branch off "main":
 
         $ git checkout -b your-bugfix-branch-name main
 
@@ -387,15 +387,15 @@ Suppose for example that the latest release was 1.2.3, and you want to include
 a bug fix in 1.2.4 (check https://github.com/pytest-dev/pytest/releases for the
 actual latest release). The procedure for this is:
 
-#. First, make sure the bug is fixed the ``master`` branch, with a regular pull
+#. First, make sure the bug is fixed the ``main`` branch, with a regular pull
    request, as described above. An exception to this is if the bug fix is not
-   applicable to ``master`` anymore.
+   applicable to ``main`` anymore.
 
-#. ``git checkout origin/1.2.x -b backport-XXXX`` # use the master PR number here
+#. ``git checkout origin/1.2.x -b backport-XXXX`` # use the main PR number here
 
 #. Locate the merge commit on the PR, in the *merged* message, for example:
 
-    nicoddemus merged commit 0f8b462 into pytest-dev:master
+    nicoddemus merged commit 0f8b462 into pytest-dev:main
 
 #. ``git cherry-pick -x -m1 REVISION`` # use the revision you found above (``0f8b462``).
 
@@ -408,7 +408,7 @@ actual latest release). The procedure for this is:
 Who does the backporting
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-As mentioned above, bugs should first be fixed on ``master`` (except in rare occasions
+As mentioned above, bugs should first be fixed on ``main`` (except in rare occasions
 that a bug only happens in a previous release). So who should do the backport procedure described
 above?
 
@@ -417,8 +417,8 @@ above?
 2. However, often the merge is done by another maintainer, in which case it is nice of them to
    do the backport procedure if they have the time.
 3. For bugs submitted by non-maintainers, it is expected that a core developer will to do
-   the backport, normally the one that merged the PR on ``master``.
+   the backport, normally the one that merged the PR on ``main``.
-4. If a non-maintainers notices a bug which is fixed on ``master`` but has not been backported
+4. If a non-maintainers notices a bug which is fixed on ``main`` but has not been backported
    (due to maintainers forgetting to apply the *needs backport* label, or just plain missing it),
    they are also welcome to open a PR with the backport. The procedure is simple and really
    helps with the maintenance of the project.

README.rst

@@ -24,7 +24,7 @@
     :target: https://github.com/pytest-dev/pytest/actions?query=workflow%3Amain
 
 .. image:: https://results.pre-commit.ci/badge/github/pytest-dev/pytest/main.svg
-   :target: https://results.pre-commit.ci/latest/github/pytest-dev/pytest/master
+   :target: https://results.pre-commit.ci/latest/github/pytest-dev/pytest/main
    :alt: pre-commit.ci status
 
 .. image:: https://img.shields.io/badge/code%20style-black-000000.svg

RELEASING.rst

@@ -32,10 +32,10 @@ and notify it as a comment in the issue.
 Minor releases
 ^^^^^^^^^^^^^^
 
-1. Create a new maintenance branch from ``master``::
+1. Create a new maintenance branch from ``main``::
 
         git fetch --all
-        git branch 5.2.x upstream/master
+        git branch 5.2.x upstream/main
         git push upstream 5.2.x
 
 2. Open a new issue and add this comment to the body::
@@ -48,10 +48,10 @@ notify it as a comment in the issue.
 Major and release candidates
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-1. Create a new maintenance branch from ``master``::
+1. Create a new maintenance branch from ``main``::
 
         git fetch --all
-        git branch 6.0.x upstream/master
+        git branch 6.0.x upstream/main
         git push upstream 6.0.x
 
 2. For a **major release**, open a new issue and add this comment in the body::
@@ -66,7 +66,7 @@ The automated workflow will publish a PR for a branch ``release-6.0.0`` and
 notify it as a comment in the issue.
 
 At this point on, this follows the same workflow as other maintenance branches: bug-fixes are merged
-into ``master`` and ported back to the maintenance branch, even for release candidates.
+into ``main`` and ported back to the maintenance branch, even for release candidates.
 
 **A note about release candidates**
 
@@ -83,7 +83,7 @@ to be executed on that platform.
 To release a version ``MAJOR.MINOR.PATCH``, follow these steps:
 
 #. For major and minor releases, create a new branch ``MAJOR.MINOR.x`` from
-   ``upstream/master`` and push it to ``upstream``.
+   ``upstream/main`` and push it to ``upstream``.
 
 #. Create a branch ``release-MAJOR.MINOR.PATCH`` from the ``MAJOR.MINOR.x`` branch.
 
@@ -114,18 +114,18 @@ Both automatic and manual processes described above follow the same steps from t
 
 #. Merge the PR.
 
-#. Cherry-pick the CHANGELOG / announce files to the ``master`` branch::
+#. Cherry-pick the CHANGELOG / announce files to the ``main`` branch::
 
        git fetch --all --prune
-       git checkout origin/master -b cherry-pick-release
+       git checkout origin/main -b cherry-pick-release
        git cherry-pick -x -m1 upstream/MAJOR.MINOR.x
 
 #. Open a PR for ``cherry-pick-release`` and merge it once CI passes. No need to wait for approvals if there were no conflicts on the previous step.
 
-#. For major and minor releases, tag the release cherry-pick merge commit in master with
+#. For major and minor releases, tag the release cherry-pick merge commit in main with
    a dev tag for the next feature release::
 
-       git checkout master
+       git checkout main
        git pull
        git tag MAJOR.{MINOR+1}.0.dev0
        git push git@github.com:pytest-dev/pytest.git MAJOR.{MINOR+1}.0.dev0

scripts/prepare-release-pr.py

@@ -3,7 +3,7 @@ This script is part of the pytest release process which is triggered manually in
 tab of the repository.
 
 The user will need to enter the base branch to start the release from (for example
-``6.1.x`` or ``master``) and if it should be a major release.
+``6.1.x`` or ``main``) and if it should be a major release.
 
 The appropriate version will be obtained based on the given branch automatically.
 

scripts/release-on-comment.py

@@ -3,7 +3,7 @@ This script is part of the pytest release process which is triggered by comments
 in issues.
 
 This script is started by the `release-on-comment.yml` workflow, which always executes on
-`master` and is triggered by two comment related events:
+`main` and is triggered by two comment related events:
 
 * https://help.github.com/en/actions/reference/events-that-trigger-workflows#issue-comment-event-issue_comment
 * https://help.github.com/en/actions/reference/events-that-trigger-workflows#issues-event-issues
@@ -16,8 +16,8 @@ The payload must contain a comment with a phrase matching this pseudo-regular ex
 
 Then the appropriate version will be obtained based on the given branch name:
 
-* a major release from master if "major" appears in the phrase in that position
+* a major release from main if "major" appears in the phrase in that position
-* a feature or bug fix release from master (based if there are features in the current changelog
+* a feature or bug fix release from main (based if there are features in the current changelog
   folder)
 * a bug fix from a maintenance branch
 
@@ -230,11 +230,11 @@ def find_next_version(base_branch: str, is_major: bool) -> str:
     breaking = list(changelog.glob("*.breaking.rst"))
     is_feature_release = features or breaking
 
-    if is_feature_release and base_branch != "master":
+    if is_feature_release and base_branch != "main":
         msg = dedent(
             f"""
             Found features or breaking changes in `{base_branch}`, and feature releases can only be
-            created from `master`:
+            created from `main`:
         """
         )
         msg += "\n".join(f"* `{x.name}`" for x in sorted(features + breaking))

src/_pytest/assertion/__init__.py

@@ -104,7 +104,7 @@ def install_importhook(config: Config) -> rewrite.AssertionRewritingHook:
 
 def pytest_collection(session: "Session") -> None:
     # This hook is only called when test modules are collected
-    # so for example not in the master process of pytest-xdist
+    # so for example not in the managing process of pytest-xdist
     # (which does not collect test modules).
     assertstate = session.config._store.get(assertstate_key, None)
     if assertstate: