GitHub and Trunk

source/Development/TestSuites/multi-repo_testing.rst

@@ -18,11 +18,11 @@ lfric_core as an example):
 .. code-block:: yaml
 
     lfric_core:
-        source: git@github.com:MetOffice/lfric_core.git
+        source: git@GitHub.com:MetOffice/lfric_core.git
         ref: <Long Hash / Tag>
 
-The ``source`` setting sets the location of the repository on github. By
-default, the test suite will access github repositories by using ssh, as shown
+The ``source`` setting sets the location of the repository on GitHub. By
+default, the test suite will access GitHub repositories by using ssh, as shown
 by the ``git@github.com`` part of the source. This line can be modified to point
 at users fork of the repository instead, eg.
 ``source: git@github.com:UserName/lfric_core.git``. The ``source`` can also be a
@@ -36,7 +36,7 @@ commit hash as part of linked pull requests.
 
 If left blank the behaviour depends on the source:
 
-* **a github source:** the Head of the repositories default branch will be used.
+* **a GitHub source:** the Head of the repositories default branch will be used.
 * **a local clone:** the state of the repository at source extraction time will be used.
   It is recommened to set a ref when setting the source to a local clone.  That way
   if you switch branches in the clone, the correct branch for testing will be used.

source/Development/inputs.rst

@@ -43,7 +43,7 @@ The project metadata can be found in the following locations:
 
 In addition to the above locations, the rose metadata is centrally mirrored on
 Met Office systems. This means that metadata that has been committed to the
-trunk can be accessed without a working copy. This may be of use when
+``main`` can be accessed without a clone. This may be of use when
 upgrading scientific suites between versions.
 
 All new namelist variables need a new entry so that the metadata loads into the
@@ -130,7 +130,7 @@ modified or added (these are a snapshot of the metadata at a release).
 If a new rose-stem app using the new metadata is also being added, then
 a "blank" upgrade macro will also need to be added with a ``BEFORE_TAG=vnX.Y``
 and a standard ``AFTER_TAG=vnX.Y_tTTTT``. This upgrade macro will allow the
-new app to be updated to the Head metadata when the branch is merged to trunk.
+new app to be updated to the Head metadata when the branch is merged to ``main``.
 The ``rose-app.conf`` for this app will require a metadata import line of
 format, ``meta=META-NAME/vnX.Y``.
 

source/Development/kgo.rst

@@ -26,7 +26,7 @@ KGO Update Process
 ------------------
 
 Getting the process right for KGO changing tickets significantly helps get such
-changes onto the trunk. When preparing your change for review:
+changes onto ``main``. When preparing your change for review:
 
 1. Run the ``all`` rose-stem group in order to make sure that all
    changes to answers have been found.
@@ -69,10 +69,10 @@ changes onto the trunk. When preparing your change for review:
 
 
         Once all the above is in place and the science and code reviews have
-        been completed then the Code Reviewer will merge your change to the
-        head of trunk. If there are merge conflicts in the checksum files then
+        been completed then the Code Reviewer will merge head of ``main`` onto
+        your branch. If there are merge conflicts in the checksum files then
         the reviewer will repeat step 3 to refresh these files. Your change is
-        then committed to trunk.
+        then merged and committed to ``main``.
 
     .. tab-item:: UM & JULES
 
@@ -85,10 +85,10 @@ changes onto the trunk. When preparing your change for review:
            details of this process.
 
         Once all of the above is in place and the science and code reviews have
-        been completed the Code Reviewer will merge the branch to the head of
-        trunk, run the tests that have changed answers and use those results
-        to install KGO files to the filesystem. Your change is then committed
-        to trunk.
+        been completed the Code Reviewer will merge head of ``main`` onto
+        your branch, run the tests that have changed answers and use those
+        results to install KGO files to the filesystem. Your branch is then
+        merged and committed to ``main``.
 
 .. tip::
 

source/Development/macros.rst

@@ -167,7 +167,7 @@ To add upgrade macros to LFRic the following steps can be followed:
    in the same ``rose-meta`` directory as the metadata being changed.
 
 3. Run the Upgrade Macro script in a test branch(see :ref:`testing`). This is
-   located in the `SimSys_Scripts github repo
+   located in the `SimSys_Scripts GitHub repo
    <https://github.com/MetOffice/SimSys_Scripts>`__ (at the MetOffice an up to
    date clone is available in $UMDIR/SimSys_Scripts). The syntax for running is:
 

source/Development/rose_stem.rst

@@ -4,7 +4,7 @@ Adding to Rose Stem Suites
 .. tip::
 
     This page is for advice on adding new tasks to a rose-stem suite. For advice
-    on running the test suite following the move to github, please see
+    on running the test suite following the move to GitHub, please see
     :ref:`testing your change <testing>`.
 
 All new changes are strongly encouraged to come with an update to the rose stem

source/Development/temp_logicals.rst

@@ -156,7 +156,7 @@ temporary logical should be removed from the code base.
 
 .. important::
 
-    Prior to a ticket containing a temporary logical being committed to the
-    trunk, the developers is expected to open a new ticket which removes the
+    Prior to a ticket containing a temporary logical being committed to
+    ``main``, the developers is expected to open a new ticket which removes the
     logical after a fixed period. This acts as an memory aid that the logical
     needs to be removed in due course.

source/Development/testing.rst

@@ -8,7 +8,7 @@ Change to the Rose Stem Suite in Git
 
 .. _github_testing:
 
-With the move to git and github, the test suites of the Simulation Systems
+With the move to git and GitHub, the test suites of the Simulation Systems
 repositories will no longer use the rose-stem infrastructure, instead becoming
 purely Cylc workflows. The only impact on the end user will be a change to the
 commands required to launch the test suite. The contents of the test suite and
@@ -29,8 +29,8 @@ following syntax,
 * ``-S VALUE=SETTING`` - these options behave as they did before, and can be
   added to the ``cylc vip`` command. See the table below for some suggestions.
 * ``-S USE_MIRRORS=`` - An example of the above settings, this is newly added
-  with the git migration. By default this is ``false`` and remote github
-  repositories will be accessed via ssh. If set to ``true``, local github
+  with the git migration. By default this is ``false`` and remote GitHub
+  repositories will be accessed via ssh. If set to ``true``, local GitHub
   mirrors will be used instead. This is recommended particularly for shared
   accounts.
 * ``-n name_of_suite`` - The new test suites will name themselves after the
@@ -45,17 +45,17 @@ For example,
 
     cylc vip -z group=developer -S USE_MIRRORS=true -n my_rose_stem_suite ./rose-stem
 
-will launch the test suite with the ``developer`` group, using the github
+will launch the test suite with the ``developer`` group, using the GitHub
 mirrors and naming it ``my_rose_stem_suite``.
 
 ``-S`` Options (non-exhaustive):
 
-* ``-S USE_MIRRORS=true`` - Use local github mirrors instead of ssh.
-* ``-S USE_TOKENS=true`` - Authenticate with github using a :ref:`personal
-  access token <github_pat>` instead of ssh. If both this and ``USE_MIRRORS``
+* ``-S USE_MIRRORS=true`` - Use local GitHub mirrors instead of ssh.
+* ``-S USE_TOKENS=true`` - Authenticate with GitHub using a :ref:`personal
+  access token <GitHub_pat>` instead of ssh. If both this and ``USE_MIRRORS``
   are true, then the mirrors will be used instead. On Monsoon, this is
   automatically set.
-* ``-S USE_HEADS=true`` - Use the head of the default branch for the github
+* ``-S USE_HEADS=true`` - Use the head of the default branch for the GitHub
   source, only intended for usage in nightly testing.
 * ``-S USE_EX[AB/CD/Z]=true`` - MetOffice only, specify the host machine for
   EX1A jobs.
@@ -71,7 +71,7 @@ for you to choose from:
 Rose-stem:
     Every repository has a rose-stem test suite that provides integration and
     regression testing - and in some cases unit tests as well. Committing
-    changes to the trunk of each repository is dependant on these tests
+    changes to the ``main`` of each repository is dependant on these tests
     passing; they are there to ensure the integrity of the codebase.
 
 Standard suites:
@@ -103,14 +103,14 @@ Test branches & Upgrade Macros
 .. tip::
 
     While we continue to use ``dev`` and ``test`` branch nomenclature from fcm,
-    in github these terms have no technical meaning and are simply a way to
+    in GitHub these terms have no technical meaning and are simply a way to
     distinguish between 2 branches.
 
 There are a few cases where testing your change will require you to make changes
-to your branch that don't want committing to trunk. To do this you can create a
-test branch. This is a branch-of-branch from your development branch and allows
-you to make those changes in an isolated environment while leaving your original
-development clean.
+to your branch that don't want committing to ``main``. To do this you can create
+a test branch. This is a branch-of-branch from your development branch and
+allows you to make those changes in an isolated environment while leaving your
+original development clean.
 
 To create a test branch:
 
@@ -159,7 +159,7 @@ commands, noting that ``--jules-path`` is only required if you have
 
 .. tip::
 
-    The ``apply_macros.py`` script is located in the `SimSys_Scripts github
+    The ``apply_macros.py`` script is located in the `SimSys_Scripts GitHub
     repo <https://github.com/MetOffice/SimSys_Scripts>`__ (at meto an up to
     date clone is available in $UMDIR/SimSys_Scripts).
 

source/FurtherDetails/dos_donts.rst

@@ -10,7 +10,7 @@ Please Do
 mitigate problems early on. This is the most common root cause of problems,
 sometimes years later.
 
-**Plan** your work aimed at the trunk across single or multiple tickets:
+**Plan** your work aimed at the ``main`` across single or multiple tickets:
     * Ensure tickets are not too big or small.
     * Coherent parts of the overall change are contained in a single ticket
     * Consider using an overarching ticket to link everything together
@@ -35,16 +35,12 @@ conflicts.
 Please Do Not
 -------------
 
-**Do not use svn commands.** Please use `FCM
-<http://metomi.github.io/fcm/doc/user_guide/>`__ for all development work.
+**Do not merge ``main`` into your branch** during the development process. To
+aid scientific evaluation changes should be kept in standalone branches based
+on the last stable version.
 
-**Do not merge the trunk into your branch** for UM, JULES, UKCA and LFRic Apps
-changes as this breaks many aspects of how TRAC and fcm work. This will cause
-diffs to display incorrectly and causes database problems when merging.
-Instead, please create a head of trunk branch and merge in your old branch.
-
-**Do not develop using head of trunk branching if not needed.** Many aspects of
-the UM, JULES and UKCA workflows rely on version branching.
+When your change is ready for Code Review, we then suggest merging in ``main``
+and resolving any conflicts.
 
 **Licensing** - Don't add code to any project (or to any branch thereof) that
 has been developed under a different license without agreement from the

source/FurtherDetails/glossary.rst

@@ -4,7 +4,7 @@ Simulation Systems Glossary
 Please suggest new entries to the Simulation Systems and Deployment Team
 
 Closed Release:
-    A release cycle where the only accepted changes to the trunk relate to a
+    A release cycle where the only accepted changes to ``main`` relate to a
     particular piece of work, either technical or scientific. A release can
     also be partially closed, with only one area of a code base locked down in
     this way, and the rest free for changes.
@@ -23,7 +23,7 @@ CodeSys Review:
     been followed. These reviews are generally completed by a member of the
     Simulation Systems and Deployment Team. Once a review has been approved
     the Code Systems Reviewer is then responsible for committing the change to
-    the trunk.
+    the ``main``.
 
 ..
     or the Core Capability Development Team (for LFRic only reviews).
@@ -45,8 +45,8 @@ Known Good Output (KGO):
     This is known as the KGO and changes that alter this require special
     treatment. For more information see :ref:`kgo`.
 
-Head of Trunk:
-    The most recent code revision on the trunk. Branches are taken from here
+Head of ``Main``:
+    The most recent code revision on ``main``. Branches are taken from here
     when the work being done *has* to be built on top of changes already made
     since the last revision.
 
@@ -80,6 +80,6 @@ Simulation Systems Governance Group:
 
 Version:
     Each release of the codebase is completed by tagging the latest revision of
-    the trunk with a version number. This version should be used for creating
+    ``stable`` with a version number. This version should be used for creating
     code branches from and will also be used by the parallel suite teams as a
     starting point for creating the next operational suite.

source/FurtherDetails/support.rst

@@ -47,4 +47,4 @@ it should be escalated to the manager of the Simulation Systems and Deployment
 Team in the first instance. They will consult appropriately to make the best
 balanced and impartial decision. If this is unsuccessful, the ultimate
 (but very rarely used) decision authority about code that may be committed to
-the trunk lies with the Simulation Systems Governance Group.
+``main`` lies with the LFRic Apps Governance Group.

source/FurtherDetails/who.rst

@@ -23,8 +23,7 @@ Developer
 Developers, in general, build on the User role:
 
 * Write and edit source code
-* Follow the Working Practices, even if their work is not intended for the
-  trunk.
+* Follow the Working Practices, even if their work is not intended for ``main``.
 * Manage their work to allow reasonable time for approvals and reviews.
 
 Notably, the Working Practices encourage and require engagement with other

source/Reviewers/committinglinkedtickets.rst

@@ -47,7 +47,7 @@ Testing linked tickets
 ----------------------
 
 With the branches from all the tickets merged into a working copy of their
-respective Head of Trunk these can all be used together to test the change.
+respective head of ``main`` these can all be used together to test the change.
 
 Details for testing multi-repository tickets are included on the
 :ref:`Working with Multiple Repositories page<multirepo>`.
@@ -61,7 +61,7 @@ UM and LFRic Apps changes will require modifying the ``dependencies.yaml`` file
 to update the source being used.
 
 * In the UM/Apps clone, edit the relevant sources and refs in the
-  ``dependencies.yaml`` file. These can be either local clones or github urls.
+  ``dependencies.yaml`` file. These can be either local clones or GitHub urls.
   See :ref:`Multi-Repo Testing <multi-repo_testing>` for more details
 
 

source/Reviewers/curaterelease.rst

@@ -71,7 +71,7 @@ developed the release branch and the other will review it (**developer** and
 * The admin **must** now revert the 2 settings above.
 * Finally, the release can be created and tagged,
 
-  * From the github repo, select ``releases`` and then ``Draft a new release``.
+  * From the GitHub repo, select ``releases`` and then ``Draft a new release``.
   * Create a new tag and title the release with the same name, eg. ``vn14.0``.
   * Select to ``Generate release notes``.
   * Then ``Publish release``.
@@ -89,15 +89,15 @@ before we have to do it for real. Typically aim for 1-2 weeks before release
 day. However, before a test release can be done, all changes to fcm-make
 config files, major rose-stem changes (things like basic upgrade macro or KGO
 updates don't necessarily need to be included) and modifications to the
-release_new_version.py script need to be on trunk, so this will cause some
+release_new_version.py script need to be on ``main``, so this will cause some
 variation as to when the test release is done from release to release.
 
 
 :ref:`Partner Testing<partner_testing>`
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 **Dependencies**
-All source code changes must be on trunk along with any rose-stem changes that
+All source code changes must be on ``main`` along with any rose-stem changes that
 affect multiple sites before partner testing can start. Ideally the test
 release will also have been completed.
 
@@ -187,8 +187,8 @@ UM Release, Standard Suites Upgrade
 UM + Apps Releases
 
 
-:ref:`Trunk and Shared Account Permissions <shared_accounts>`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:ref:`GitHub and Shared Account Permissions <shared_accounts>`
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 **Dependencies**
 None