Update default branch name (#1532)

Signed-off-by: Michael Dolan <michdolan@gmail.com> Co-authored-by: Patrick Hodoul <patrick.hodoul@autodesk.com>
2021-11-08 09:57:36 -05:00
parent ce85939bb0
commit 64dccadba1
39 changed files with 86 additions and 86 deletions
@@ -52,7 +52,7 @@ This charter (the &quot;Charter&quot;) sets forth the responsibilities and proce
 7. Intellectual Property Policy
  * **a.** Participants acknowledge that the copyright in all new contributions shall be retained by the copyright holder as independent works of authorship and that no contributor or copyright holder will be required to assign copyrights to the Project.
  * **b.** Except as described in Section 7.c., all code contributions to the Project are subject to the following:
-    * **i.** All new inbound code contributions to the Project must be made using the **BSD 3-Clause License (available here: [https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/LICENSE](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/LICENSE))** (the &quot;Project License&quot;).
+    * **i.** All new inbound code contributions to the Project must be made using the **BSD 3-Clause License (available here: [https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/LICENSE](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/LICENSE))** (the &quot;Project License&quot;).
    * **ii.** All new inbound code contributions must:
      1. be made pursuant to a duly executed Project Contribution License Agreement (the &quot;CLA&quot;), available on the Project&#39;s web site; and
      2. be accompanied by a Developer Certificate of Origin ([http://developercertificate.org](http://developercertificate.org)) sign-off in the source code system that is submitted through a TSC-approved contribution process which will bind the authorized contributor and, if not self-employed, their employer to the applicable license;
@@ -36,7 +36,7 @@ Attendees:
 * Infrastructure
  * GitHub repo needs migrating to the ASWF organisation
  * **TODO** - John Mertic to coordinate with Steve Winslow at the LF to complete.
-  * https://github.com/AcademySoftwareFoundation/tac/blob/master/process/contributing.md
+  * https://github.com/AcademySoftwareFoundation/tac/blob/main/process/contributing.md
 * Require that any existing copyright notices are reviewed and amended by the current stated owners if their respective legal agrees.
  * Once migrated will enable DCO sign off checking and CLA checks.
 * Sub-discussion on the option of separate sign off for committer vs developer sign off.
@@ -44,9 +44,9 @@ Attendees:
    * Do a patch against 1.1 that fixes a few minor things?
        * Consensus is that we should make 1.1.1 with some important non-breaking patches and release that fix right away.
        * **TODO**: Patrick will send Slack the list of candidate commits for a 1.1.1.
-    * Do we make an intermediate release from master before v2.0? People want a "developer preview" to be able to use the new GPU path.
+    * Do we make an intermediate release from main before v2.0? People want a "developer preview" to be able to use the new GPU path.
        * Patrick reluctant to make a full release.
-        * Proposal: just make a "developer preview" tag in master to designate a point we think is stable and has some helpful new features, but we don't promise any support or compatibility with the eventual v2.
+        * Proposal: just make a "developer preview" tag in main to designate a point we think is stable and has some helpful new features, but we don't promise any support or compatibility with the eventual v2.
            * Down side: people will use it and expect us to support it.
            * No consensus that this is a good idea. Mark especially doesn't like unsupported dev preview tag.
            * But v2 will NOT be ready by SIGGRAPH 2019. In light of this, Mark thinks maybe we should have a real intermediate release.
@@ -26,7 +26,7 @@ Attendees:
        - Doug: As established in the initial 2.0 proposal, this is not feasible.
        - The plan remains to release a complete feature set when the full v2 roadmap is completed.
    - Community concern is that the v2 release schedule is unknown, and time between OCIO releases is long.
-        - This can make planning for software vendors challenging, but preliminary implementation of the v2 interface is possible now from master for testing.
+        - This can make planning for software vendors challenging, but preliminary implementation of the v2 interface is possible now from main for testing.
        - Autodesk discussing an official roadmap and insight on a potential release window. Stay tuned.
        - Long PR review cycles contribute to development slowdowns:
            - Most PRs are merged with the 2 week single reviewer clause.
@@ -37,7 +37,7 @@ Attendees:
                - PRs are becoming smaller, more focused, which should help with review accessability
            - **TODO**: Doug/Patrick to review and report back on what project management changes could help them
    - Larry: Should we have a known commit for testing a given feature (i.e. GPU renderer) for internal testing purposes.
-        - Doug: Testing off of master at any given time is stable, and ideal.
+        - Doug: Testing off of main at any given time is stable, and ideal.

 * ASWF/LF CI update from TAC meeting
    - Thanh presented comparison of Circle CI and current Jenkins infrastructure:
@@ -43,7 +43,7 @@ Attendees:
    - Any recommendations from LF regarding what to add to CI?
        - Thanh: Some options are Nexus IQ, WhiteSource for security, Sonar Qube for static.
        - Thanh is doing some investigation for TAC, we will follow closely for recommendations.
-    - John provide the following link: https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/security.md
+    - John provide the following link: https://github.com/coreinfrastructure/best-practices-badge/blob/main/doc/security.md
    - Chair asked John if we were moving too slowly, John: no.

 * 1.1.1 Release
@@ -29,7 +29,7 @@ Apologies:
        - Waiting approval

 * Azure CI Build:
-    - Larry G.: Needs to build OCIO with some dependency master branch to trap coming issues?
+    - Larry G.: Needs to build OCIO with some dependency main branch to trap coming issues?
        - Larry G. Only some libraries:
            As OpenEXR is an indirect dependency, perhaps not needed.
            But OIIO could be a good candidate.
@@ -38,7 +38,7 @@ Apologies:
      Meatballs” images with Sony.
    - Kevin: We also need to update the LICENSE on the OCIO website
    - Michael: That is pulled from GitHub, but currently from the RB-1.1 
-      branch. Since the license cleanup work is being done in master, is it Ok 
+      branch. Since the license cleanup work is being done in main, is it Ok 
      to wait for a 2.0 release next year to update the site?
    - John: That should be Ok.
    - Kevin: Let’s make a note to not forget it.
@@ -30,8 +30,8 @@ Attendees:
 * RB-1.1
    - Michael: Following the approval for another minor release (*TSC meeting 2019-08-12*),
      Travis & AppVeyor (i.e. the former CI build) are back for the RB-1.1 branch only.
-        - AppVeyor uses RB-1.1 & master branch
-            - **TODO**: Sean will help to disable master.
+        - AppVeyor uses RB-1.1 & main branch
+            - **TODO**: Sean will help to disable main.
        - Travis triggers new warnings/errors.
          Check [PR 798](https://github.com/imageworks/OpenColorIO/pull/798) for details.
            - Agreed to fix them.
@@ -28,7 +28,7 @@ Apologies:
    - Doug raised that pull request #831 removes macros specific to these versions of GCC.
    - Patrick raised that as we add more C+11 features the more we will be restricted.
    - Kevin thinks we should definitely drop support for GCC 3.
-    - Patrick thought dropping GCC 3 would be fine and should be done in the master branch.
+    - Patrick thought dropping GCC 3 would be fine and should be done in the main branch.

 * Azure CI build
    - Patrick raised that the communication between Azure and Github is broken.
@@ -26,7 +26,7 @@ Attendees:
    - To document the policy concerning repository rights vs. roles.

 * Branch protected
-    - Agreement to only protect `master`, `RB-**` and `gh-pages`.
+    - Agreement to only protect `main`, `RB-**` and `gh-pages`.

 * Stalled pull requests
    - Agreement to not have any automatic removal of stalled pull requests.
@@ -32,7 +32,7 @@ Attendees:
 * ASWF GSoC discussion
    - Polled Slack for project ideas for ASWF's application to Google Summer of 
      Code, and submitted PR to: 
-      `https://github.com/AcademySoftwareFoundation/tac/blob/master/gsoc/README.md`_
+      `https://github.com/AcademySoftwareFoundation/tac/blob/main/gsoc/README.md`_
    - In summary, four projects initially proposed:
          - Add Metal, Vulkan, or CUDA language support to GPU renderer
          - Restore Java bindings
@@ -52,7 +52,7 @@ Attendees:
    
 * Python bindings
    - Michael: Resumed work on pybind11 bindings. Got everything up to date with 
-      master.
+      main.
    - Mei Chu (Imageworks) is interested in helping with this work, potentially 
      designing unit tests to start.
          - Mei: Looking forward to getting more involved in OCIO
@@ -61,7 +61,7 @@ Apologies: Michael Dolan
        in what types of EXR images may be read (e.g. looking for a specific channel layout,
        no multi-part support).
    - Kevin: A quick scan of the EXR codec shows it only really outputs 16 bit RGB, RGBA, YCbCr.
-         https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/exr.c#L1691 
+         https://github.com/FFmpeg/FFmpeg/blob/main/libavcodec/exr.c#L1691 
        - Mark: Is that integer 16 bit? 
        - Kevin: Yes, integers.
    - Mark: One approach would be to make video filters for OCIO ColorSpaceTransform and
@@ -70,7 +70,7 @@ Apologies:
    - Carol: A lot of it can hopefully be to work with DCC vendors to help them 
      update their docs as well, and to understand coming changes. Then we can 
      point our docs to theirs.
-    - Michael: The [Compatible Software](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/docs/CompatibleSoftware.rst) 
+    - Michael: The [Compatible Software](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/docs/CompatibleSoftware.rst) 
      page of the OCIO website was updated recently and contains many 
      up-to-date documentation links.
    - Doug: Also may want to add OCIO developers to the list of consumers, to 
@@ -87,7 +87,7 @@ Apologies:
    - Sean: Docstring header PR is in. Need another PR for pybind11 docstring 
      header, and another for reorganization of doc structure. The RTD page 
      points to official OCIO repo, so we're live now, but API docs and new 
-      style is missing. Any changes to master are getting pushed to RTD now. 
+      style is missing. Any changes to main are getting pushed to RTD now. 
      Not as much holding back docs as it seems. 
    - Simran: An event hook in GH communicates to RTD when to update the site.
    - Michael: Can we open GH issues for logical chunks of work?
@@ -100,10 +100,10 @@ Apologies:
      begin that?
    - Kevin: If we create them together we are saying they are the same. If 
      separated, might be different.
-    - Patrick: Where do we put the tag? In master or in RB-2.0?
-    - Mark: Have it in both, and cherry pick master changes into RB-2.0.
-    - Patrick: Only consequence is master will be tagged as RC.
-    - All agree to create tag in master and branch RB-2.0 from that.
+    - Patrick: Where do we put the tag? In main or in RB-2.0?
+    - Mark: Have it in both, and cherry pick main changes into RB-2.0.
+    - Patrick: Only consequence is main will be tagged as RC.
+    - All agree to create tag in main and branch RB-2.0 from that.

 * General discussion:
    - Kevin: If we are concerned with ABI compatibility, should we put 
@@ -69,7 +69,7 @@ Attendees:
    - Alexa: Better to link to DCC vendors own guides.
    - Michael: There is some of that on the site now in the Compatible Software 
      page, which was updated recently: 
-      [Compatible Software](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/docs/CompatibleSoftware.rst)
+      [Compatible Software](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/docs/CompatibleSoftware.rst)
    - Carol: Tricky to know which vendors to include tutorials for.
    - Alexa: Could be better to explain the config, and what each part means. 
      It's difficult to find everything right now.
@@ -30,7 +30,7 @@ Recording on Zoom cloud:
   - Mark: Is ociocheck crashing for anyone?
   - Doug: We will look into it.
   - *UPDATE:* We tested this and it is working.  We found a case where illegal
-(too long) spi1d LUTs caused a crash in master.  These LUTs were not flagged as
+(too long) spi1d LUTs caused a crash in main.  These LUTs were not flagged as
 being illegal in OCIO v1 and would have had incorrect results.

 **STRING UTILS**
@@ -218,7 +218,7 @@ discussion about the questions raised.

 **GENERAL DISCUSSION**

-   - Mark:  I was testing master and found that role names are now
+   - Mark:  I was testing main and found that role names are now
 case-sensitive.  This is a change from OCIO v1.
   - Doug:  Are we agreed we want case-insensitive behavior?  Same for color
 spaces too?   Group agreed.
@@ -204,12 +204,12 @@ endif()

 if(NOT DEFINED OCIO_NAMESPACE)
 	set(OCIO_NAMESPACE "OpenColorIO_v${OpenColorIO_VERSION_MAJOR}_${OpenColorIO_VERSION_MINOR}${OpenColorIO_VERSION_RELEASE_TYPE}" CACHE STRING 
-        "Specify the master OCIO C++ namespace: Options include OpenColorIO OpenColorIO_<YOURFACILITY> etc.")
+        "Specify the main OCIO C++ namespace: Options include OpenColorIO OpenColorIO_<YOURFACILITY> etc.")
 elseif(OCIO_NAMESPACE STREQUAL "")
    message(FATAL_ERROR "A namespace cannot be empty.")
 else()
    set(OCIO_NAMESPACE "OpenColorIO_${OCIO_NAMESPACE}_v${OpenColorIO_VERSION_MAJOR}_${OpenColorIO_VERSION_MINOR}${OpenColorIO_VERSION_RELEASE_TYPE}" CACHE STRING 
-        "Specify the master OCIO C++ namespace: Options include OpenColorIO OpenColorIO_<YOURFACILITY> etc.")
+        "Specify the main OCIO C++ namespace: Options include OpenColorIO OpenColorIO_<YOURFACILITY> etc.")
    message(STATUS "Setting namespace to '${OCIO_NAMESPACE}' as none was specified.")
 endif()

@@ -91,7 +91,7 @@ can be merged.
  [Corporate Contributor Licence Agreement](https://docs.linuxfoundation.org/lfx/easycla/contributors/corporate-contributor).

 The OCIO CLA's are the standard forms used by Linux Foundation projects and
-[recommended by the ASWF TAC](https://github.com/AcademySoftwareFoundation/tac/blob/master/process/contributing.md#contributor-license-agreement-cla).
+[recommended by the ASWF TAC](https://github.com/AcademySoftwareFoundation/tac/blob/main/process/contributing.md#contributor-license-agreement-cla).

 ### Commit Sign-Off

@@ -113,7 +113,7 @@ can be merged. Otherwise the EasyCLA system will provide instructions on
 signing a CLA, or request inclusion in an existing corporate CLA approved list.

 See the
-[ASWF TAC CONTRIBUTING.md](https://github.com/AcademySoftwareFoundation/tac/blob/master/process/contributing.md#contribution-sign-off)
+[ASWF TAC CONTRIBUTING.md](https://github.com/AcademySoftwareFoundation/tac/blob/main/process/contributing.md#contribution-sign-off)
 file for more information on this requirement.

 ### Copyright Notices
@@ -161,15 +161,15 @@ You are now ready to contribute.
 The OpenColorIO repository has a relatively straight-forward structure, and a
 simple branching and merging strategy.

-All development work is done directly on the master branch. This represents the
+All development work is done directly on the main branch. This represents the
 bleeding-edge of the project and any contributions should be done on top of it.

-After sufficient work is done on the master branch and OCIO leadership
+After sufficient work is done on the main branch and OCIO leadership
 determines that a release is due, we will bump the relevant internal versioning
 and tag a commit with the corresponding version number, e.g. v2.0.1. Each Minor
 version also has its own “Release Branch”, e.g. RB-1.1. This marks a branch of
 code dedicated to that Major.Minor version, which allows upstream bug fixes to
-be cherry-picked to a given version while still allowing the master branch to
+be cherry-picked to a given version while still allowing the main branch to
 continue forward onto higher versions. This basic repository structure keeps
 maintenance low, while remaining simple to understand.

@@ -183,7 +183,7 @@ Please review [PROCESS.md](PROCESS.md) for important procedures related to
 making changes to OpenColorIO. Small bug fixes and documentation changes can be
 more informal, but modifications to core OpenColorIO functionality MUST follow
 the 
-[Core Library Changes](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/PROCESS.md#Core-Library-Changes) process.
+[Core Library Changes](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/PROCESS.md#Core-Library-Changes) process.

 The development cycle for a code change should follow this protocol:

@@ -210,9 +210,9 @@ who may discuss, offer constructive feedback, request changes, or approve
 the work.

 7. Upon receiving the required number of Committer approvals (as outlined in 
-[Required Approvals](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/PROCESS.md#Required-Approvals)), 
+[Required Approvals](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/PROCESS.md#Required-Approvals)), 
 a Committer other than the PR contributor may squash and merge changes into the 
-master branch.
+main branch.

 See also (from the OCIO Developer Guide):
 * [Getting started](http://opencolorio.org/developers/getting_started.html)
@@ -254,7 +254,7 @@ version with three numbers: Major.Minor.Patch, where:

 ## Creating a Release

-To create a new release from the master branch:
+To create a new release from the main branch:

 1. Update the release notes in ``CHANGELOG.md`` with a high-level summary of
   the features and improvements. Also include the summary in the Release
@@ -28,7 +28,7 @@ across the project so are treated as core changes.
   [ocio-dev](https://lists.aswf.io/g/ocio-dev), but are ultimately brought to a 
   TSC meeting where consensus can be reached around the proposal's relevance 
   and approach. TSC meetings are public and meeting notes are posted to the 
-   [OCIO repo](https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/master/ASWF/meetings/tsc) 
+   [OCIO repo](https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/main/ASWF/meetings/tsc) 
   within days of a meeting for a permanent record of decisions.
 2. Following acceptance of the proposal by the TSC, an issue is created in 
   GitHub to present a design proposal. A period of further community 
@@ -1301,7 +1301,7 @@ CHM_FILE               =
 HHC_LOCATION           =

 # The GENERATE_CHI flag controls if a separate .chi index file is generated
-# (YES) or that it should be included in the master .chm file (NO).
+# (YES) or that it should be included in the main .chm file (NO).
 # The default value is: NO.
 # This tag requires that the tag GENERATE_HTMLHELP is set to YES.

@@ -8,7 +8,7 @@ Charter
 =======

 See `Charter.md 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/ASWF/Charter.md>`__ 
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/ASWF/Charter.md>`__ 
 on GitHub.

 Technical Charter (the “Charter”) for OpenColorIO a Series of LF Projects, LLC
@@ -193,7 +193,7 @@ Project must comply with the terms of this Charter.

   -  **i.** All new inbound code contributions to the Project must be
      made using the **BSD 3-Clause License (available
-      here: **\ https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/LICENSE\ **)**
+      here: **\ https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/LICENSE\ **)**
      (the “Project License”).
   -  **ii.** All new inbound code contributions must:

@@ -12,7 +12,7 @@ follows the open source software best practice policies of the ASWF TAC with
 the guidance from the Linux Foundation.

 See `CONTRIBUTING.md 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/CONTRIBUTING.md>`__ 
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/CONTRIBUTING.md>`__ 
 for more information.

 CLA
@@ -35,7 +35,7 @@ then you should use the :ref:`Corporate Contributor Licence Agreement <ccla>`.

 The OCIO CLA's are the standard forms used by Linux Foundation projects and 
 `recommended by the ASWF TAC 
-<https://github.com/AcademySoftwareFoundation/tac/blob/master/process/contributing.md#contributor-license-agreement-cla>`__.
+<https://github.com/AcademySoftwareFoundation/tac/blob/main/process/contributing.md#contributor-license-agreement-cla>`__.

 .. _ccla:

@@ -43,7 +43,7 @@ CLA-corporate
 +++++++++++++

 See `CLA-corporate.md 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/ASWF/CLA-corporate.md>`__ 
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/ASWF/CLA-corporate.md>`__ 
 on GitHub.

 ----
@@ -108,7 +108,7 @@ CLA-individual
 ++++++++++++++

 See `CLA-individual.md 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/ASWF/CLA-individual.md>`__ 
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/ASWF/CLA-individual.md>`__ 
 on GitHub.

 ----
@@ -12,7 +12,7 @@ library should abide by that license unless otherwised approved by the OCIO
 TSC and ASWF Governing Board.

 See `LICENSE 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/LICENSE>`__ 
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/LICENSE>`__ 
 on GitHub.

 ----
@@ -222,7 +222,7 @@ are loaded, etc.
 CPU CODE PATH
 +++++++++++++

-The master list of ops is then optimized, and stored internally in the processor.
+The main list of ops is then optimized, and stored internally in the processor.

 .. code-block:: cpp

@@ -260,7 +260,7 @@ After all ops have been applied, the results are copied back to the source
 GPU CODE PATH
 +++++++++++++

-#. The master list of ops is partitioned into 3 ordered lists:
+#. The main list of ops is partitioned into 3 ordered lists:

 - As many ops as possible from the BEGINNING of the op-list that can be done
  analytically in shader text. (called gpu-preops)
@@ -276,7 +276,7 @@ analyze the op-stream metadata and determine the appropriate allocation to use.
 interserting a forward allocation to the end of the pre-ops, and the inverse
 allocation to the start of the lattice ops.

-See https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/src/core/NoOps.cpp#L183
+See https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/src/core/NoOps.cpp#L183

 #. The 3 lists of ops are then optimized individually, and stored on the processor.
 The Lut3d is computed by applying the gpu-lattice ops, on the CPU, to a lut3d
@@ -311,7 +311,7 @@ Features exposed for customization by the user include:
 - Selection of shaper function: Log2 or Dolby PQ

 **CTL Source**
-The configuration depends on the **ACES 1.0.3** release. The release contains a number of file renames and the new ACEScct color space and a number of minor bug fixes and small additions, but is otherwise very similar as the master **ACES 1.0.2** release. 
+The configuration depends on the **ACES 1.0.3** release. The release contains a number of file renames and the new ACEScct color space and a number of minor bug fixes and small additions, but is otherwise very similar as the main **ACES 1.0.2** release. 

 The CTL is available here:

@@ -142,7 +142,7 @@ Example:


 Note that if the per-shot lut is not found, you can control whether a
-fallback LUT succeeds based on if it's in the master location. You can
+fallback LUT succeeds based on if it's in the main location. You can
 also use this for multiple levels (show, shot, etc).

 Advanced option: If some shots use .cc files, and some use 3d-luts
@@ -10,12 +10,12 @@ Getting started
 Checking Out The Codebase
 *************************

-The master code repository is available on Github:  http://github.com/AcademySoftwareFoundation/OpenColorIO
+The main code repository is available on Github:  http://github.com/AcademySoftwareFoundation/OpenColorIO

 For those unfamiliar with git, the wonderful part about it is that even though
-only a limited number people have write access to the master repository, anyone
+only a limited number people have write access to the main repository, anyone
 is free to create, and even check in, changes to their own local git repository. 
-Your local changes will not automatically be pushed back to the master
+Your local changes will not automatically be pushed back to the main
 repository, so everyone feel free to informally play around with the codebase.
 Also - unlike svn - when you download the git repository you have a full copy of
 the project's history (including revision history, logs, etc), so the majority
@@ -47,7 +47,7 @@ To check out a read-write version of the repository (GitHub acct required)::
    Receiving objects: 100% (2220/2220), 2.89 MiB | 2.29 MiB/s, done.
    Resolving deltas: 100% (1434/1434), done.

-Both read + read/write users should then add the `AcademySoftwareFoundation/OpenColorIO <https://github.com/AcademySoftwareFoundation/OpenColorIO>`_ master branch
+Both read + read/write users should then add the `AcademySoftwareFoundation/OpenColorIO <https://github.com/AcademySoftwareFoundation/OpenColorIO>`_ main branch
 as a remote. This will allow you to more easily fetch updates as they become
 available::

@@ -104,33 +104,33 @@ commits, and in the case of in-progress feature branches, you'll need to merge
 those changes or rebase your commits on top of them regularly to stay up to 
 date. To update your fork from upstream run the::

-    git checkout master
-    git pull upstream master && git push origin master
+    git checkout main
+    git pull upstream main && git push origin main

-The first command makes sure you have the master branch checked out, and the 
+The first command makes sure you have the main branch checked out, and the 
 second combines an upstream pull (getting all the new commits to bring your
 local clone up to date) and an origin push (updating your fork's remote 
-master). Following these commands the master branch will be identical between
+main). Following these commands the main branch will be identical between
 the OpenColorIO repository and your fork.

 To merge these changes into a feature branch (making the branch able to merge 
-with the upstream master), run::
+with the upstream main), run::

    git checkout myFeature
-    git merge master
+    git merge main

 git will report any merge conflicts encountered and allow you to resolve them 
 locally prior to committing the merge.

 Alternatively you can rebase the changes into your branch, which will replay
-your branch commits on top of the latest master branch commits. A rebase should
+your branch commits on top of the latest main branch commits. A rebase should
 only be used if you are the only contributor to a branch. Since rebasing alters
 the branch's commit history, a force push is required to push the changes to
 the remote repository, which can be problematic for others contributing to the
 same branch. To rebase, run::

    git checkout myFeature
-    git rebase master
+    git rebase main

 Follow the interactive instructions that git provides during the rebase to 
 resolve merge conflicts at each replayed commit. Update your remote branch
@@ -28,4 +28,4 @@ help reproduce code-related defects.

 If the issue you are reporting is related to a security vulnerability, please 
 follow the reporting procedures outlined in the `OpenColorIO security policy 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/SECURITY.md>`__.
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/SECURITY.md>`__.
@@ -10,16 +10,16 @@ Repository structure
 The OpenColorIO repository has a relatively straight-forward structure, and a 
 simple branching and merging strategy.

-All development work is done directly on the master branch. This represents 
+All development work is done directly on the main branch. This represents 
 the bleeding-edge of the project and any contributions should be done on top of 
 it.

-After sufficient work is done on the master branch and OCIO leadership 
+After sufficient work is done on the main branch and OCIO leadership 
 determines that a release is due, we will bump the relevant internal versioning 
 and tag a commit with the corresponding version number, e.g. v2.0.1. Each Minor 
 version also has its own “Release Branch”, e.g. RB-1.1. This marks a branch of 
 code dedicated to that Major.Minor version, which allows upstream bug fixes to 
-be cherry-picked to a given version while still allowing the master branch to 
+be cherry-picked to a given version while still allowing the main branch to 
 continue forward onto higher versions. This basic repository structure keeps 
 maintenance low, while remaining simple to understand.

@@ -57,8 +57,8 @@ assistance.

 * Pull the latest changes from upstream::

-    git checkout master
-    git pull upstream master
+    git checkout main
+    git pull upstream main

 * Create a branch for your contribution::

@@ -88,12 +88,12 @@ assistance.
 * Wait for code review and comments from the community.

 * At various points in the review process other pull requests will have been 
-  merged into OpenColorIO master, at which point merging of your PR will be 
+  merged into OpenColorIO main, at which point merging of your PR will be 
  blocked with the message "This branch is out-of-date with the base branch". 
  Clicking the "Update branch" button will automatically merge the updated 
  branch into your feature branch. This step may need to be repeated multiple
  times depending on current commit activity.

 See `CONTRIBUTING.md 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/CONTRIBUTING.md#Repository-Structure>`__ 
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/CONTRIBUTING.md#Repository-Structure>`__ 
 for more information.
@@ -37,7 +37,7 @@ The OCIO C++ test framework is based on the `OpenImageIO test framework
 <https://github.com/OpenImageIO/oiio/blob/master/src/include/OpenImageIO/unittest.h>`__.

 The macros defined in `UnitTest.h 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/tests/testutils/UnitTest.h>`__
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/tests/testutils/UnitTest.h>`__
 are used to define tests and assert expected behavior:

 * ``OCIO_ADD_TEST``: Define a test and add it to the named test ``group``. 
@@ -71,7 +71,7 @@ class has a dedicated ``TestCase`` class with a ``test_*`` method per specific
 test.

 Test cases must be imported into `OpenColorIOTestSuite.py 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/tests/python/OpenColorIOTestSuite.py>`__
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/tests/python/OpenColorIOTestSuite.py>`__
 and added to the ``suite`` method to be included in ``ctest`` execution.

 Java
@@ -25,7 +25,7 @@ Website: `<http://www.adobe.com/products/aftereffects.html>`__

 Documentation :

- See `src/aftereffects <http://github.com/AcademySoftwareFoundation/OpenColorIO/tree/master/src/aftereffects>`__ if you are interested in building your own OCIO plugins.
+- See `src/aftereffects <http://github.com/AcademySoftwareFoundation/OpenColorIO/tree/main/src/aftereffects>`__ if you are interested in building your own OCIO plugins.

 - Pre-built binaries are also available for `download <http://fnordware.blogspot.com/2012/05/opencolorio-for-after-effects.html>`__, courtesy of `fnordware <http://www.fnordware.com>`__.

@@ -62,13 +62,13 @@ C++

 The core OpenColorIO API is available for use in C++. Minimal code examples are also available in the source code distribution. 

-Website: `<http://github.com/AcademySoftwareFoundation/OpenColorIO/tree/master/include/OpenColorIO>`__
+Website: `<http://github.com/AcademySoftwareFoundation/OpenColorIO/tree/main/include/OpenColorIO>`__

 Examples:

- `ocioconvert <https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/master/src/apps/ocioconvert>`__
+- `ocioconvert <https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/main/src/apps/ocioconvert>`__

- `ociodisplay <https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/master/src/apps/ociodisplay>`__
+- `ociodisplay <https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/main/src/apps/ociodisplay>`__

 Documentation:

@@ -167,7 +167,7 @@ Java (Beta)

 The OpenColorIO API is available for use in Java. This integration is currently considered a work in progress, and should not be relied upon for critical production work.

-Website: `<https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/master/src/bindings/java>`__
+Website: `<https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/main/src/bindings/java>`__


 Katana (Foundry)
@@ -318,7 +318,7 @@ Python

 The OpenColorIO API is available for use in Python.

-Website: `<https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/master/src/bindings/python>`__
+Website: `<https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/main/src/bindings/python>`__

 Documentation:

@@ -10,7 +10,7 @@ Downloads
 * Sample OCIO Configurations -- `.zip <http://github.com/imageworks/OpenColorIO-Configs/zipball/master>`__ `.tar.gz <http://github.com/imageworks/OpenColorIO-Configs/tarball/master>`__
 * Reference Images v1.0v4 -- `.tgz <http://code.google.com/p/opencolorio/downloads/detail?name=ocio-images.1.0v4.tgz>`__
 * Core Library v2.0.0 -- `.zip <https://github.com/AcademySoftwareFoundation/OpenColorIO/archive/v2.0.0.zip>`__ `.tar.gz <https://github.com/AcademySoftwareFoundation/OpenColorIO/archive/v2.0.0.tar.gz>`__
-* Core Library dev -- `.zip <http://github.com/AcademySoftwareFoundation/OpenColorIO/zipball/master>`__ `.tar.gz <http://github.com/AcademySoftwareFoundation/OpenColorIO/tarball/master>`__
+* Core Library dev -- `.zip <http://github.com/AcademySoftwareFoundation/OpenColorIO/zipball/main>`__ `.tar.gz <http://github.com/AcademySoftwareFoundation/OpenColorIO/tarball/main>`__

 Per-version updates: :ref:`changelog-main`.

@@ -20,7 +20,7 @@ Build instructions: :ref:`building-from-source`.

 Contributor License Agreements
 ******************************
-Please see the `OCIO GitHub repository <https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/master/docs/aswf>`__
+Please see the `OCIO GitHub repository <https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/main/docs/aswf>`__

 Deprecated Downloads
 ********************
@@ -10,7 +10,7 @@ Quick Start for Developers
 Get started by following the :ref:`installation` instructions to build OCIO from 
 source.  You will want to make sure to build the command-line tools as well as the
 library itself, so you should install OpenImageIO before building.  Note that 
-active development of OCIO v2 is happening in the master branch.
+active development of OCIO v2 is happening in the main branch.

 Grab the available configuration files (and the sample images, if you want) from
 :ref:`downloads`.
@@ -89,7 +89,7 @@ Some optional components also depend on:
 - OpenImageIO >= 2.1.9 (for apps including ocioconvert)

 Example bash scripts are provided in 
-`share/ci/scripts <https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/master/share/ci/scripts>`_ 
+`share/ci/scripts <https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/main/share/ci/scripts>`_ 
 for installing some dependencies. These are used by OpenColorIO CI so are 
 regularly tested on their noted platforms. The ``install_docs_env.sh``
 script will install all dependencies for building OCIO documentation and is 
@@ -4,7 +4,7 @@ The OCIO homepage is built with Hugo which you will need to build the static HTM

 ## Building For Development

-**Step 1:** Fork or clone the repository, be sure to make a new branch for your changes, follow [OCIO contribution guidelines](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/CONTRIBUTING.md) for branch naming!
+**Step 1:** Fork or clone the repository, be sure to make a new branch for your changes, follow [OCIO contribution guidelines](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/CONTRIBUTING.md) for branch naming!

 ```shell
 git clone https://github.com/AcademySoftwareFoundation/OpenColorIO.git
@@ -34,7 +34,7 @@ Navigate to http://localhost:1313 in your web browser of choice and see your cha

 **Step 5:** Submit a PR

-Check out the [OCIO guidelines](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/CONTRIBUTING.md) for information about this too!
+Check out the [OCIO guidelines](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/CONTRIBUTING.md) for information about this too!

 ## Building the Static Website

@@ -52,4 +52,4 @@ hugo -D --minify --themesDir ../..

 It should appear in a folder labelled "public"

-Once your PR has been accepted for the changes to the master branch submit another PR replacing the content of the gh-pages branch with the content from Hugo's output.  Note that the old site and documentation still live in the gh-pages branch in the `old/` directory, when you replace the contents of the branch please be sure to keep that entire folder as is.
+Once your PR has been accepted for the changes to the main branch submit another PR replacing the content of the gh-pages branch with the content from Hugo's output.  Note that the old site and documentation still live in the gh-pages branch in the `old/` directory, when you replace the contents of the branch please be sure to keep that entire folder as is.
@@ -13,7 +13,7 @@ namespace
 {

 // Reference:
-//   https://github.com/python/cpython/blob/master/Objects/memoryobject.c
+//   https://github.com/python/cpython/blob/main/Objects/memoryobject.c
 //   https://docs.python.org/3.7/c-api/arg.html#numbers
 //   https://numpy.org/devdocs/user/basics.types.html