Change default branch from master to main

.github/workflows/ci-pre-commit.yml

@@ -2,9 +2,9 @@ name: Linting
 
 on:
   push:
-    branches: master
+    branches: main
   pull_request:
-    branches: master
+    branches: main
 
 jobs:
   checks:

README.rst

@@ -6,9 +6,9 @@ Distributed
 A library for distributed computation.  See documentation_ for more details.
 
 .. _documentation: https://distributed.dask.org
-.. |Linux/Windows Build Status| image:: https://github.com/dask/distributed/workflows/Tests/badge.svg?branch=master
+.. |Linux/Windows Build Status| image:: https://github.com/dask/distributed/workflows/Tests/badge.svg?branch=main
    :target: https://github.com/dask/distributed/actions?query=workflow%3A%22Tests%22
-.. |MacOS Build Status| image:: https://github.com/dask/distributed/workflows/MacOS%20tests/badge.svg?branch=master
+.. |MacOS Build Status| image:: https://github.com/dask/distributed/workflows/MacOS%20tests/badge.svg?branch=main
    :target: https://github.com/dask/distributed/actions?query=workflow%3A%22MacOS+tests%22
 .. |Doc Status| image:: https://readthedocs.org/projects/distributed/badge/?version=latest
    :target: https://distributed.dask.org

distributed/_version.py

@@ -196,7 +196,7 @@ def git_versions_from_keywords(keywords, tag_prefix, verbose):
         # refs/heads/ and refs/tags/ prefixes that would let us distinguish
         # between branches and tags. By ignoring refnames without digits, we
         # filter out many common branch names like "release" and
-        # "stabilization", as well as "HEAD" and "master".
+        # "stabilization", as well as "HEAD" and "main".
         tags = set([r for r in refs if re.search(r"\d", r)])
         if verbose:
             print("discarding '%s', no digits" % ",".join(refs - tags))

distributed/dashboard/templates/performance_report.html

@@ -1,6 +1,6 @@
 {% extends "file.html" %}
-{# See https://github.com/bokeh/bokeh/blob/master/bokeh/core/_templates/file.html #}
+{# See https://github.com/bokeh/bokeh/blob/main/bokeh/core/_templates/file.html #}
 
 {% block preamble %}
 <link rel="shortcut icon" href="https://docs.dask.org/en/latest/_static/images/favicon.ico" />
-{% endblock %}
+{% endblock %}

docs/release-procedure.md

@@ -1,3 +1,3 @@
 Distributed follows a similar procedure for releasing as the core Dask project.
 
-See https://github.com/dask/dask/blob/master/docs/release-procedure.md for instructions.
+See https://github.com/dask/dask/blob/main/docs/release-procedure.md for instructions.

docs/source/develop.rst

@@ -39,9 +39,9 @@ To keep a fork in sync with the upstream source::
    git remote add upstream [email protected]:dask/distributed.git
    git remote -v
    git fetch -a upstream
-   git checkout master
-   git pull upstream master
-   git push origin master
+   git checkout main
+   git pull upstream main
+   git push origin main
 
 Test
 ----
@@ -92,7 +92,7 @@ The test suite contains three kinds of tests
     same event loop in the main thread.  These are good for testing complex
     logic and inspecting the state of the system directly.  They are also
     easier to debug and cause the fewest problems with shutdowns.
-2.  ``def test_foo(client)``: Tests with multiple processes forked from the master
+2.  ``def test_foo(client)``: Tests with multiple processes forked from the main
     process.  These are good for testing the synchronous (normal user) API and
     when triggering hard failures for resilience tests.
 3.  ``popen``: Tests that call out to the command line to start the system.
@@ -114,15 +114,15 @@ using the ``@gen_cluster`` style of test, e.g.
         assert isinstance(s, Scheduler)
         assert isinstance(a, Worker)
         assert isinstance(b, Worker)
-    
+
         future = c.submit(inc, 1)
         assert isinstance(future, Future)
         assert future.key in c.futures
-    
+
         # result = future.result()  # This synchronous API call would block
         result = await future
         assert result == 2
-    
+
         assert future.key in s.tasks
         assert future.key in a.data or future.key in b.data
 

docs/source/diagnosing-performance.rst

@@ -39,7 +39,7 @@ The main way to observe these times is with the task stream plot on the
 scheduler's ``/status`` page where the colors of the bars correspond to the
 colors listed above.
 
-.. image:: https://raw.githubusercontent.com/dask/dask-org/master/images/bokeh-task-stream.gif
+.. image:: https://raw.githubusercontent.com/dask/dask-org/main/images/bokeh-task-stream.gif
    :alt: Dask task stream
    :width: 50%
 
@@ -73,7 +73,7 @@ any of the bars in the profile will zoom the user into just that section, as is
 typical with most profiling tools.  There is a timeline at the bottom of the
 page to allow users to select different periods in time.
 
-.. image:: https://raw.githubusercontent.com/dask/dask-org/master/images/daskboard-profile.gif
+.. image:: https://raw.githubusercontent.com/dask/dask-org/main/images/daskboard-profile.gif
    :alt: Dask profiler
    :width: 70%
 

docs/source/priority.rst

@@ -69,7 +69,7 @@ Dask uses the following priorities, in order:
 3.  **Graph Structure**: Within any given computation (a compute or persist
     call) Dask orders tasks in such a way as to minimize the memory-footprint
     of the computation.  This is discussed in more depth in the
-    `task ordering documentation <https://github.com/dask/dask/blob/master/dask/order.py>`_.
+    `task ordering documentation <https://github.com/dask/dask/blob/main/dask/order.py>`_.
 
 If multiple tasks each have exactly the same priorities outlined above, then
 the order in which tasks arrive at a worker, in a last in first out manner,

docs/source/scheduling-policies.rst

@@ -78,7 +78,7 @@ can be used to break ties and helps us to prioritize nodes with longer critical
 paths and nodes with many children.  The actual algorithms used are somewhat
 more complex and are described in detail in `dask/order.py`_
 
-.. _`dask/order.py`: https://github.com/dask/dask/blob/master/dask/order.py
+.. _`dask/order.py`: https://github.com/dask/dask/blob/main/dask/order.py
 
 Initial Task Placement
 ~~~~~~~~~~~~~~~~~~~~~~
@@ -122,7 +122,7 @@ scheduler, and workers at various points in the computation.
     computing deeply before broadly, preferring critical paths, preferring
     nodes with many dependencies, etc..  This is the same logic used by the
     single-machine scheduler and lives in `dask/order.py
-    <https://github.com/dask/dask/blob/master/dask/order.py>`_.
+    <https://github.com/dask/dask/blob/main/dask/order.py>`_.
 2.  When the graph reaches the scheduler the scheduler changes each of these
     numeric priorities into a tuple of two numbers, the first of which is an
     increasing counter, the second of which is the client-generated priority

versioneer.py

@@ -606,7 +606,7 @@ def git_versions_from_keywords(keywords, tag_prefix, verbose):
         # refs/heads/ and refs/tags/ prefixes that would let us distinguish
         # between branches and tags. By ignoring refnames without digits, we
         # filter out many common branch names like "release" and
-        # "stabilization", as well as "HEAD" and "master".
+        # "stabilization", as well as "HEAD" and "main".
         tags = set([r for r in refs if re.search(r'\d', r)])
         if verbose:
             print("discarding '%%s', no digits" %% ",".join(refs - tags))
@@ -998,7 +998,7 @@ def git_versions_from_keywords(keywords, tag_prefix, verbose):
         # refs/heads/ and refs/tags/ prefixes that would let us distinguish
         # between branches and tags. By ignoring refnames without digits, we
         # filter out many common branch names like "release" and
-        # "stabilization", as well as "HEAD" and "master".
+        # "stabilization", as well as "HEAD" and "main".
         tags = set([r for r in refs if re.search(r'\d', r)])
         if verbose:
             print("discarding '%s', no digits" % ",".join(refs - tags))