[ovs-dev] Rename primary development branch as main.

Recently OVS adopted a policy of using the inclusive naming word list v1
[1, 2].

In keeping with this policy rename the primary development branch from
'master' to 'main'. This patch does not actually make that change,
but rather updates references to the branch in the source tree.
It is intended to be applied at (approximately) the same time that the
change is made.

OVS is currently hosted on GitHub. We can expect the following behaviour
after the rename:

1. GitHub pull requests against are renamed branch are automatically
   re-homed on new branch
2. GitHub Issues do not seem to be affected - at least the test issue I
   created had no association with a branch
3. URLs accessed via the GitHub web UI are automatically renamed
   (so long as a new branch called master is not created).
4. Using the git cli command, fetch will fetch the new branch (main),
   and fetch -p will remove (prune) the old branch (master)

[1] df5e5cf ("Documentation: Add section on inclusive language.")
[2] https://inclusivenaming.org/word-lists/

Signed-off-by: Simon Horman <horms@ovn.org>
---
Notes:

* Now is the time to raise any concerns regarding this patch.
  I plan to repost in approximately a week.
  And implement the change another week after that.

* If you have an automation that fetches the master branch then
  the suggested action is:
  1. Before the branch rename occurs: update the automation to pull main an
     fall back to pulling master if that fails
  2. After the rename occurs: Update the automation to only fetch main

* The appveyor change is atomic, I'm open to suggestions on this.
  Also, I am unsure how to test this change.

* There are some references to the primary development branch in documentation
  regarding the kernel datapath. As the Kernel datapath is no longer
  present in the primary development branch I have posted a patch to
  remove that documentation.

  https://mail.openvswitch.org/pipermail/ovs-dev/2024-March/412685.html
---
 .../internals/committer-responsibilities.rst       | 12 +++---
 .../internals/contributing/backporting-patches.rst | 12 +++---
 Documentation/internals/release-process.rst        | 50 +++++++++++-----------
 Documentation/intro/install/dpdk.rst               |  2 +-
 Documentation/intro/install/fedora.rst             |  2 +-
 Documentation/intro/install/general.rst            |  2 +-
 Documentation/intro/install/rhel.rst               |  2 +-
 Documentation/topics/language-bindings.rst         |  2 +-
 Documentation/tutorials/faucet.rst                 |  6 +--
 Documentation/tutorials/ovs-conntrack.rst          |  2 +-
 NEWS                                               |  4 +-
 README.rst                                         |  2 +-
 appveyor.yml                                       |  8 ++--
 13 files changed, 54 insertions(+), 52 deletions(-)

On Thu, Mar 21, 2024 at 10:09:20AM +0000, Simon Horman wrote:

...

> diff --git a/appveyor.yml b/appveyor.yml

...

> @@ -23,7 +23,7 @@ install:
>      New-Item -ItemType Directory -Force -Path C:\ovs-build-downloads
>  
>      # Find and download the latest stable OpenSSl 3.0.
> -    $URL = "https://raw.githubusercontent.com/slproweb/opensslhashes/master/win32_openssl_hashes.json"
> +    $URL = "https://raw.githubusercontent.com/slproweb/opensslhashes/main/win32_openssl_hashes.json"
>      $webData = (Invoke-WebRequest -Uri $URL).content | ConvertFrom-Json
>      $source = ($webData.files.PSObject.Properties | Where-Object {
>          $_.Value.basever   -match "3.0.*" -and

Yikes, I see the hunk above is wrong.
I will drop it in v2.

...

Bleep bloop.  Greetings Simon Horman, I am a robot and I have tried out your patch.
Thanks for your contribution.

I encountered some error that I wasn't expecting.  See the details below.


checkpatch:
WARNING: Line is 110 characters long (recommended limit is 79)
#377 FILE: README.rst:11:
.. image:: https://ci.appveyor.com/api/projects/status/github/openvswitch/ovs?branch=main&svg=true&retina=true

Lines checked: 415, Warnings: 1, Errors: 0


Please check this out.  If you feel there has been an error, please email aconole@redhat.com

Thanks,
0-day Robot

CC: ovs-discuss for visibility.

It seems like this change will affect ovn-fake-multinode project
and ovn-heater as they are cloning 'master' branch by default.
Also the OVN project itself is cloning OVS master branch in one
of the CI workflows.


On 3/21/24 11:09, Simon Horman wrote:
> Recently OVS adopted a policy of using the inclusive naming word list v1
> [1, 2].
> 
> In keeping with this policy rename the primary development branch from
> 'master' to 'main'. This patch does not actually make that change,
> but rather updates references to the branch in the source tree.
> It is intended to be applied at (approximately) the same time that the
> change is made.
> 
> OVS is currently hosted on GitHub. We can expect the following behaviour
> after the rename:
> 
> 1. GitHub pull requests against are renamed branch are automatically
>    re-homed on new branch
> 2. GitHub Issues do not seem to be affected - at least the test issue I
>    created had no association with a branch
> 3. URLs accessed via the GitHub web UI are automatically renamed
>    (so long as a new branch called master is not created).
> 4. Using the git cli command, fetch will fetch the new branch (main),
>    and fetch -p will remove (prune) the old branch (master)

We may want to mention that users will need to update their .git/config
to point their checked out branches to the new upstream branch.  I don't
think git will do that automatically.

> 
> [1] df5e5cf ("Documentation: Add section on inclusive language.")
> [2] https://inclusivenaming.org/word-lists/
> 
> Signed-off-by: Simon Horman <horms@ovn.org>
> ---
> Notes:
> 
> * Now is the time to raise any concerns regarding this patch.
>   I plan to repost in approximately a week.
>   And implement the change another week after that.
> 
> * If you have an automation that fetches the master branch then
>   the suggested action is:
>   1. Before the branch rename occurs: update the automation to pull main an
>      fall back to pulling master if that fails
>   2. After the rename occurs: Update the automation to only fetch main
> 
> * The appveyor change is atomic, I'm open to suggestions on this.
>   Also, I am unsure how to test this change.

While most of the changes in this patch are inconsequential, i.e. will
not break anything when applied, the AppVeyor change will break CI.

So, we should not make the change in atomic fashion.  I suggest we add
(not replace!) the 'main' to the list of branches in the appveyor.yml
as a separate patch.  This patch will need to be applied *before*
renaming the branch.  It should be fine to apply it even a few days or
a week before the change is made.  Then the rest of the changes in this
patch should be applied *after* the branch is re-named.

This should ensure the continuity of CI for AppVeyor.  This is basically
the same thing as described in 'If you have an automation' section, but
applied to our own in-tree CI.

For the testing, you can install AppVeyor to your own private fork.
See https://www.appveyor.com/docs/ .

Couple small comments inline.

> 
> * There are some references to the primary development branch in documentation
>   regarding the kernel datapath. As the Kernel datapath is no longer
>   present in the primary development branch I have posted a patch to
>   remove that documentation.
> 
>   https://mail.openvswitch.org/pipermail/ovs-dev/2024-March/412685.html
> ---
>  .../internals/committer-responsibilities.rst       | 12 +++---
>  .../internals/contributing/backporting-patches.rst | 12 +++---
>  Documentation/internals/release-process.rst        | 50 +++++++++++-----------
>  Documentation/intro/install/dpdk.rst               |  2 +-
>  Documentation/intro/install/fedora.rst             |  2 +-
>  Documentation/intro/install/general.rst            |  2 +-
>  Documentation/intro/install/rhel.rst               |  2 +-
>  Documentation/topics/language-bindings.rst         |  2 +-
>  Documentation/tutorials/faucet.rst                 |  6 +--
>  Documentation/tutorials/ovs-conntrack.rst          |  2 +-
>  NEWS                                               |  4 +-
>  README.rst                                         |  2 +-
>  appveyor.yml                                       |  8 ++--
>  13 files changed, 54 insertions(+), 52 deletions(-)
> 
> diff --git a/Documentation/internals/committer-responsibilities.rst b/Documentation/internals/committer-responsibilities.rst
> index c35fd708913b..eed2e017678a 100644
> --- a/Documentation/internals/committer-responsibilities.rst
> +++ b/Documentation/internals/committer-responsibilities.rst
> @@ -73,14 +73,14 @@ If it is someone else's change, then you can ask the original submitter to
>  address it. Regardless, you need to ensure that the problem is fixed in a
>  timely way. The definition of "timely" depends on the severity of the problem.
>  
> -If a bug is present on master and other branches, fix it on master first, then
> +If a bug is present on main and other branches, fix it on main first, then
>  backport the fix to other branches. Straightforward backports do not require
> -additional review (beyond that for the fix on master).
> +additional review (beyond that for the fix on main).
>  
> -Feature development should be done only on master. Occasionally it makes sense
> +Feature development should be done only on main. Occasionally it makes sense
>  to add a feature to the most recent release branch, before the first actual
>  release of that branch. These should be handled in the same way as bug fixes,
> -that is, first implemented on master and then backported.
> +that is, first implemented on main and then backported.
>  
>  Keep the authorship of a commit clear by maintaining a correct list of
>  "Signed-off-by:"s. If a confusing situation comes up, as it occasionally does,
> @@ -99,7 +99,7 @@ Pre-Push Hook
>  -------------
>  
>  The following script can be helpful because it provides an extra
> -chance to check for mistakes while pushing to the master branch of OVS
> +chance to check for mistakes while pushing to the main branch of OVS
>  or OVN.  If you would like to use it, install it as ``hooks/pre-push``
>  in your ``.git`` directory and make sure to mark it as executable with
>  ``chmod +x``.  For maximum utility, make sure ``checkpatch.py`` is in
> @@ -118,7 +118,7 @@ in your ``.git`` directory and make sure to mark it as executable with
>  
>    while read local_ref local_sha1 remote_ref remote_sha1; do
>        case $remote_ref in
> -          refs/heads/master)
> +          refs/heads/main)
>                n=0
>                while read sha
>                do
> diff --git a/Documentation/internals/contributing/backporting-patches.rst b/Documentation/internals/contributing/backporting-patches.rst
> index 0ef7f5beb9b0..050daba23f3e 100644
> --- a/Documentation/internals/contributing/backporting-patches.rst
> +++ b/Documentation/internals/contributing/backporting-patches.rst
> @@ -43,10 +43,10 @@ within Open vSwitch, but is broadly applied in the following fashion:
>  - Maintainers backport changes from a development branch to release branches.
>  
>  With regards to Open vSwitch user space code and code that does not comprise
> -the Linux datapath and compat code, the development branch is `master` in the
> +the Linux datapath and compat code, the development branch is `main` in the
>  Open vSwitch repository. Patches are applied first to this branch, then to the
>  most recent `branch-X.Y`, then earlier `branch-X.Z`, and so on. The most common
> -kind of patch in this category is a bugfix which affects master and other
> +kind of patch in this category is a bugfix which affects main and other
>  branches.
>  
>  For Linux datapath code, the primary development branch is in the `net-next`_
> @@ -64,15 +64,15 @@ Changes to userspace components
>  -------------------------------
>  
>  Patches which are fixing bugs should be considered for backporting from
> -`master` to release branches. Open vSwitch contributors submit their patches
> -targeted to the `master` branch, using the ``Fixes`` tag described in
> -:doc:`submitting-patches`. The maintainer first applies the patch to `master`,
> +`main` to release branches. Open vSwitch contributors submit their patches
> +targeted to the `main` branch, using the ``Fixes`` tag described in
> +:doc:`submitting-patches`. The maintainer first applies the patch to `main`,
>  then backports the patch to each older affected tree, as far back as it goes or
>  at least to all currently supported branches. This is usually each branch back
>  to the oldest maintained LTS release branch or the last 4 release branches if
>  the oldest LTS is newer.
>  
> -If the fix only affects a particular branch and not `master`, contributors
> +If the fix only affects a particular branch and not `main`, contributors
>  should submit the change with the target branch listed in the subject line of
>  the patch. Contributors should list all versions that the bug affects. The
>  ``git format-patch`` argument ``--subject-prefix`` may be used when posting the
> diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst
> index d939c2d3ab8b..f0c745dc6de0 100644
> --- a/Documentation/internals/release-process.rst
> +++ b/Documentation/internals/release-process.rst
> @@ -34,33 +34,33 @@ or the #openvswitch IRC channel.
>  Release Strategy
>  ----------------
>  
> -Open vSwitch feature development takes place on the "master" branch.
> -Ordinarily, new features are rebased against master and applied directly.  For
> +Open vSwitch feature development takes place on the "main" branch.
> +Ordinarily, new features are rebased against main and applied directly.  For
>  features that take significant development, sometimes it is more appropriate to
> -merge a separate branch into master; please discuss this on ovs-dev in advance.
> +merge a separate branch into main; please discuss this on ovs-dev in advance.
>  
>  The process of making a release has the following stages.  See `Release
>  Scheduling`_ for the timing of each stage:
>  
> -1. "Soft freeze" of the master branch.
> +1. "Soft freeze" of the main branch.
>  
>     During the freeze, we ask committers to refrain from applying patches that
>     add new features unless those patches were already being publicly discussed
>     and reviewed before the freeze began.  Bug fixes are welcome at any time.
>     Please propose and discuss exceptions on ovs-dev.
>   
> -2. Fork a release branch from master, named for the expected release number,
> +2. Fork a release branch from main, named for the expected release number,
>     e.g. "branch-2.3" for the branch that will yield Open vSwitch 2.3.x.
>  
>     Release branches are intended for testing and stabilization.  At this stage
>     and in later stages, they should receive only bug fixes, not new features.
>     Bug fixes applied to release branches should be backports of corresponding
> -   bug fixes to the master branch, except for bugs present only on release
> +   bug fixes to the main branch, except for bugs present only on release
>     branches (which are rare in practice).
>  
>     At this stage, sometimes there can be exceptions to the rule that a release
>     branch receives only bug fixes.  Like bug fixes, new features on release
> -   branches should be backports of the corresponding commits on the master
> +   branches should be backports of the corresponding commits on the main
>     branch.  Features to be added to release branches should be limited in scope
>     and risk and discussed on ovs-dev before creating the branch.
>  
> @@ -125,10 +125,10 @@ intermediate branches).
>  Release Numbering
>  -----------------
>  
> -The version number on master should normally end in .90.  This indicates that
> +The version number on main should normally end in .90.  This indicates that
>  the Open vSwitch version is "almost" the next version to branch.
>  
> -Forking master into branch-x.y requires two commits to master.  The first is
> +Forking main into branch-x.y requires two commits to main.  The first is
>  titled "Prepare for x.y.0" and increments the version number to x.y.  This is
>  the initial commit on branch-x.y.  The second is titled "Prepare for post-x.y.0
>  (x.y.90)" and increments the version number to x.y.90.
> @@ -146,23 +146,23 @@ Release Scheduling
>  Open vSwitch makes releases at the following six-month cadence.  All dates are
>  approximate:
>  
> -+---------------+----------------+--------------------------------------+
> -| Time (months) | Dates          | Stage                                |
> -+---------------+----------------+--------------------------------------+
> -| T             | Mar 1, Sep 1   | Begin x.y release cycle              |
> -+---------------+----------------+--------------------------------------+
> -| T + 4         | Jul 1, Jan 1   | "Soft freeze" master for x.y release |
> -+---------------+----------------+--------------------------------------+
> -| T + 4.5       | Jul 15, Jan 15 | Fork branch-x.y from master          |
> -+---------------+----------------+--------------------------------------+
> -| T + 5.5       | Aug 15, Feb 15 | Release version x.y.0                |
> -+---------------+----------------+--------------------------------------+
> ++---------------+----------------+------------------------------------+
> +| Time (months) | Dates          | Stage                              |
> ++---------------+----------------+------------------------------------+
> +| T             | Mar 1, Sep 1   | Begin x.y release cycle            |
> ++---------------+----------------+------------------------------------+
> +| T + 4         | Jul 1, Jan 1   | "Soft freeze" main for x.y release |
> ++---------------+----------------+------------------------------------+
> +| T + 4.5       | Jul 15, Jan 15 | Fork branch-x.y from main          |
> ++---------------+----------------+------------------------------------+
> +| T + 5.5       | Aug 15, Feb 15 | Release version x.y.0              |
> ++---------------+----------------+------------------------------------+
>  
>  How to Branch
>  -------------
>  
> -To branch "master" for the eventual release of OVS version x.y.0,
> -prepare two patches against master:
> +To branch "main" for the eventual release of OVS version x.y.0,
> +prepare two patches against main:
>  
>  1. "Prepare for x.y.0." following the model of commit 836d1973c56e
>     ("Prepare for 2.11.0.").
> @@ -172,12 +172,12 @@ prepare two patches against master:
>  
>  Post both patches to ovs-dev.  Get them reviewed in the usual way.
>  
> -Apply both patches to master, and create branch-x.y by pushing only
> +Apply both patches to main, and create branch-x.y by pushing only
>  the first patch.  The following command illustrates how to do both of
>  these at once assuming the local repository HEAD points to the
>  "Prepare for post-x.y.0" commit:
>  
> -        git push origin HEAD:master HEAD^:refs/heads/branch-x.y
> +        git push origin HEAD:main HEAD^:refs/heads/branch-x.y
>  
>  Branching should be announced on ovs-dev.
>  
> @@ -200,7 +200,7 @@ Follow these steps to release version x.y.z of OVS from branch-x.y.
>  
>  4. Apply the patches to branch-x.y.
>  
> -5. If z = 0, apply the first patch (only) to master.
> +5. If z = 0, apply the first patch (only) to main.
>  
>  6. Sign a tag vx.y.z "Open vSwitch version x.y.z" and push it to the
>     repo.
> diff --git a/Documentation/intro/install/dpdk.rst b/Documentation/intro/install/dpdk.rst
> index c92e598d7ae8..f1646322c7e3 100644
> --- a/Documentation/intro/install/dpdk.rst
> +++ b/Documentation/intro/install/dpdk.rst
> @@ -174,7 +174,7 @@ Additional information can be found in :doc:`general`.
>    daemon will run as a non-root user.  This implies that you must have a
>    working IOMMU.  Visit the `RHEL README`__ for additional information.
>  
> -__ https://github.com/openvswitch/ovs/blob/master/rhel/README.RHEL.rst
> +__ https://github.com/openvswitch/ovs/blob/main/rhel/README.RHEL.rst
>  
>  
>  Possible issues when enabling AVX512
> diff --git a/Documentation/intro/install/fedora.rst b/Documentation/intro/install/fedora.rst
> index 49fad844c7f7..f8a6bb6b6033 100644
> --- a/Documentation/intro/install/fedora.rst
> +++ b/Documentation/intro/install/fedora.rst
> @@ -146,7 +146,7 @@ purpose.
>  Refer to the `RHEL README`__ for additional usage and configuration
>  information.
>  
> -__ https://github.com/openvswitch/ovs/blob/master/rhel/README.RHEL.rst
> +__ https://github.com/openvswitch/ovs/blob/main/rhel/README.RHEL.rst
>  
>  Reporting Bugs
>  --------------
> diff --git a/Documentation/intro/install/general.rst b/Documentation/intro/install/general.rst
> index 17c154268054..2b3959a14370 100644
> --- a/Documentation/intro/install/general.rst
> +++ b/Documentation/intro/install/general.rst
> @@ -37,7 +37,7 @@ repository, which you can clone into a directory named "ovs" with::
>  
>      $ git clone https://github.com/openvswitch/ovs.git
>  
> -Cloning the repository leaves the "master" branch initially checked
> +Cloning the repository leaves the "main" branch initially checked
>  out.  This is the right branch for general development.  If, on the
>  other hand, if you want to build a particular released version, you
>  can check it out by running a command such as the following from the
> diff --git a/Documentation/intro/install/rhel.rst b/Documentation/intro/install/rhel.rst
> index f2151d890717..e442fca0c0ed 100644
> --- a/Documentation/intro/install/rhel.rst
> +++ b/Documentation/intro/install/rhel.rst
> @@ -211,7 +211,7 @@ implemented.  Refer to `README.RHEL.rst`__ in the source tree or
>  /usr/share/doc/openvswitch/README.RHEL.rst in the installed openvswitch package
>  for details.
>  
> -__ https://github.com/openvswitch/ovs/blob/master/rhel/README.RHEL.rst
> +__ https://github.com/openvswitch/ovs/blob/main/rhel/README.RHEL.rst
>  
>  Reporting Bugs
>  --------------
> diff --git a/Documentation/topics/language-bindings.rst b/Documentation/topics/language-bindings.rst
> index 414f7c73fa38..15958d76da93 100644
> --- a/Documentation/topics/language-bindings.rst
> +++ b/Documentation/topics/language-bindings.rst
> @@ -49,7 +49,7 @@ required dependencies, run:
>  
>  or install `python3-netaddr` and `python3-pyparsing`.
>  
> -__ https://github.com/openvswitch/ovs/tree/master/python/ovs
> +__ https://github.com/openvswitch/ovs/tree/main/python/ovs
>  
>  Third-Party Bindings
>  --------------------
> diff --git a/Documentation/tutorials/faucet.rst b/Documentation/tutorials/faucet.rst
> index 6aa4d39aa8ab..33e4543e4023 100644
> --- a/Documentation/tutorials/faucet.rst
> +++ b/Documentation/tutorials/faucet.rst
> @@ -27,7 +27,7 @@ OVS Faucet Tutorial
>  
>  This tutorial demonstrates how Open vSwitch works with a general-purpose
>  OpenFlow controller, using the Faucet controller as a simple way to get
> -started.  It was tested with the "master" branch of Open vSwitch and version
> +started.  It was tested with the "main" branch of Open vSwitch and version
>  1.6.15 of Faucet.  It does not use advanced or recently added features in OVS
>  or Faucet, so other versions of both pieces of software are likely to work
>  equally well.
> @@ -68,7 +68,7 @@ approaches:
>       $ git clone https://github.com/openvswitch/ovs.git
>       $ cd ovs
>  
> -   The default checkout is the master branch.  You will need to use the master
> +   The default checkout is the main branch.  You will need to use the main
>     branch for this tutorial as it includes some functionality required for this
>     tutorial.
>  
> @@ -84,7 +84,7 @@ approaches:
>  
>       The default behaviour for some of the commands used in this tutorial
>       changed in Open vSwitch versions 2.9.x and 2.10.x which breaks the
> -     tutorial.  We recommend following step 3 and building master from
> +     tutorial.  We recommend following step 3 and building main from
>       source or using a system Open vSwitch that is version 2.8.x or older.
>  
>     If it is successful, you will find yourself in a subshell environment, which
> diff --git a/Documentation/tutorials/ovs-conntrack.rst b/Documentation/tutorials/ovs-conntrack.rst
> index e8a58c4eb298..6b0b73cd1173 100644
> --- a/Documentation/tutorials/ovs-conntrack.rst
> +++ b/Documentation/tutorials/ovs-conntrack.rst
> @@ -35,7 +35,7 @@ to match on the TCP segments from connection setup to connection tear down.
>  It will use OVS with the Linux kernel module as the datapath for this
>  tutorial. (The datapath that utilizes the openvswitch kernel module to do
>  the packet processing in the Linux kernel)
> -It was tested with the "master" branch of Open vSwitch.
> +It was tested with the "main" branch of Open vSwitch.
>  
>  Definitions
>  -----------
> diff --git a/NEWS b/NEWS
> index c9e4064e67a7..9c3e59455d29 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -4,7 +4,9 @@ Post-v3.3.0
>       * Conntrack now supports 'random' flag for selecting ports in a range
>         while natting and 'persistent' flag for selection of the IP address
>         from a range.
> -

Please, keep two empty lines between sections for different releases.

> +  - The primary development branch has been renamed from 'master' to 'main'.
> +    The OVS tree remains hosted on GitHub.
> +    https://github.com/openvswitch/ovs.git
>  
>  v3.3.0 - 16 Feb 2024
>  --------------------
> diff --git a/README.rst b/README.rst
> index a2c234f4d17c..ca9e386c2069 100644
> --- a/README.rst
> +++ b/README.rst
> @@ -8,7 +8,7 @@ Open vSwitch
>  
>  .. image:: https://github.com/openvswitch/ovs/workflows/Build%20and%20Test/badge.svg
>      :target: https://github.com/openvswitch/ovs/actions
> -.. image:: https://ci.appveyor.com/api/projects/status/github/openvswitch/ovs?branch=master&svg=true&retina=true
> +.. image:: https://ci.appveyor.com/api/projects/status/github/openvswitch/ovs?branch=main&svg=true&retina=true
>      :target: https://ci.appveyor.com/project/blp/ovs/history
>  .. image:: https://api.cirrus-ci.com/github/openvswitch/ovs.svg
>      :target: https://cirrus-ci.com/github/openvswitch/ovs
> diff --git a/appveyor.yml b/appveyor.yml
> index 29cc44d6c6f6..65e29eb4e3be 100644
> --- a/appveyor.yml
> +++ b/appveyor.yml
> @@ -2,7 +2,7 @@ version: 1.0.{build}
>  image: Visual Studio 2019
>  branches:
>    only:
> -  - master
> +  - main

Should be done in two stages as described above.

>  configuration:
>    - Debug
>    - Release
> @@ -23,7 +23,7 @@ install:
>      New-Item -ItemType Directory -Force -Path C:\ovs-build-downloads
>  
>      # Find and download the latest stable OpenSSl 3.0.
> -    $URL = "https://raw.githubusercontent.com/slproweb/opensslhashes/master/win32_openssl_hashes.json"
> +    $URL = "https://raw.githubusercontent.com/slproweb/opensslhashes/main/win32_openssl_hashes.json"

As mentioned in the other email, this is not a correct change
as it is not our repo.

>      $webData = (Invoke-WebRequest -Uri $URL).content | ConvertFrom-Json
>      $source = ($webData.files.PSObject.Properties | Where-Object {
>          $_.Value.basever   -match "3.0.*" -and
> @@ -74,6 +74,6 @@ build_script:
>           c:\OpenvSwitch-$env:CONFIGURATION.msi
>  
>  after_build:
> -- ps: 7z a C:\ovs-master-$env:CONFIGURATION.zip C:\openvswitch
> -- ps: Push-AppveyorArtifact C:\ovs-master-$env:CONFIGURATION.zip
> +- ps: 7z a C:\ovs-main-$env:CONFIGURATION.zip C:\openvswitch
> +- ps: Push-AppveyorArtifact C:\ovs-main-$env:CONFIGURATION.zip
>  - ps: Push-AppveyorArtifact C:\OpenvSwitch-$env:CONFIGURATION.msi
> 

Best regards, Ilya Maximets.

On 3/21/24 13:32, Ilya Maximets wrote:
> CC: ovs-discuss for visibility.
> 

Thanks for the heads up, Ilya!

> It seems like this change will affect ovn-fake-multinode project
> and ovn-heater as they are cloning 'master' branch by default.

I opened draft PRs for ovn-fake-multinode and ovn-heater:
https://github.com/ovn-org/ovn-fake-multinode/pull/88
https://github.com/ovn-org/ovn-heater/pull/197

We can trigger CI recheck on those and merge them when the OVS change
actually happens.

> Also the OVN project itself is cloning OVS master branch in one
> of the CI workflows.
> 

There also are other references to "OVS master branch" in OVN.  I'll
prepare a patch to fix that up and we can merge it after the OVS change
lands.

Regards,
Dumitru

> 
> On 3/21/24 11:09, Simon Horman wrote:
>> Recently OVS adopted a policy of using the inclusive naming word list v1
>> [1, 2].
>>
>> In keeping with this policy rename the primary development branch from
>> 'master' to 'main'. This patch does not actually make that change,
>> but rather updates references to the branch in the source tree.
>> It is intended to be applied at (approximately) the same time that the
>> change is made.
>>
>> OVS is currently hosted on GitHub. We can expect the following behaviour
>> after the rename:
>>
>> 1. GitHub pull requests against are renamed branch are automatically
>>    re-homed on new branch
>> 2. GitHub Issues do not seem to be affected - at least the test issue I
>>    created had no association with a branch
>> 3. URLs accessed via the GitHub web UI are automatically renamed
>>    (so long as a new branch called master is not created).
>> 4. Using the git cli command, fetch will fetch the new branch (main),
>>    and fetch -p will remove (prune) the old branch (master)
> 
> We may want to mention that users will need to update their .git/config
> to point their checked out branches to the new upstream branch.  I don't
> think git will do that automatically.
> 
>>
>> [1] df5e5cf ("Documentation: Add section on inclusive language.")
>> [2] https://inclusivenaming.org/word-lists/
>>
>> Signed-off-by: Simon Horman <horms@ovn.org>
>> ---
>> Notes:
>>
>> * Now is the time to raise any concerns regarding this patch.
>>   I plan to repost in approximately a week.
>>   And implement the change another week after that.
>>
>> * If you have an automation that fetches the master branch then
>>   the suggested action is:
>>   1. Before the branch rename occurs: update the automation to pull main an
>>      fall back to pulling master if that fails
>>   2. After the rename occurs: Update the automation to only fetch main
>>
>> * The appveyor change is atomic, I'm open to suggestions on this.
>>   Also, I am unsure how to test this change.
> 
> While most of the changes in this patch are inconsequential, i.e. will
> not break anything when applied, the AppVeyor change will break CI.
> 
> So, we should not make the change in atomic fashion.  I suggest we add
> (not replace!) the 'main' to the list of branches in the appveyor.yml
> as a separate patch.  This patch will need to be applied *before*
> renaming the branch.  It should be fine to apply it even a few days or
> a week before the change is made.  Then the rest of the changes in this
> patch should be applied *after* the branch is re-named.
> 
> This should ensure the continuity of CI for AppVeyor.  This is basically
> the same thing as described in 'If you have an automation' section, but
> applied to our own in-tree CI.
> 
> For the testing, you can install AppVeyor to your own private fork.
> See https://www.appveyor.com/docs/ .
> 
> Couple small comments inline.
> 
>>
>> * There are some references to the primary development branch in documentation
>>   regarding the kernel datapath. As the Kernel datapath is no longer
>>   present in the primary development branch I have posted a patch to
>>   remove that documentation.
>>
>>   https://mail.openvswitch.org/pipermail/ovs-dev/2024-March/412685.html
>> ---
>>  .../internals/committer-responsibilities.rst       | 12 +++---
>>  .../internals/contributing/backporting-patches.rst | 12 +++---
>>  Documentation/internals/release-process.rst        | 50 +++++++++++-----------
>>  Documentation/intro/install/dpdk.rst               |  2 +-
>>  Documentation/intro/install/fedora.rst             |  2 +-
>>  Documentation/intro/install/general.rst            |  2 +-
>>  Documentation/intro/install/rhel.rst               |  2 +-
>>  Documentation/topics/language-bindings.rst         |  2 +-
>>  Documentation/tutorials/faucet.rst                 |  6 +--
>>  Documentation/tutorials/ovs-conntrack.rst          |  2 +-
>>  NEWS                                               |  4 +-
>>  README.rst                                         |  2 +-
>>  appveyor.yml                                       |  8 ++--
>>  13 files changed, 54 insertions(+), 52 deletions(-)
>>
>> diff --git a/Documentation/internals/committer-responsibilities.rst b/Documentation/internals/committer-responsibilities.rst
>> index c35fd708913b..eed2e017678a 100644
>> --- a/Documentation/internals/committer-responsibilities.rst
>> +++ b/Documentation/internals/committer-responsibilities.rst
>> @@ -73,14 +73,14 @@ If it is someone else's change, then you can ask the original submitter to
>>  address it. Regardless, you need to ensure that the problem is fixed in a
>>  timely way. The definition of "timely" depends on the severity of the problem.
>>  
>> -If a bug is present on master and other branches, fix it on master first, then
>> +If a bug is present on main and other branches, fix it on main first, then
>>  backport the fix to other branches. Straightforward backports do not require
>> -additional review (beyond that for the fix on master).
>> +additional review (beyond that for the fix on main).
>>  
>> -Feature development should be done only on master. Occasionally it makes sense
>> +Feature development should be done only on main. Occasionally it makes sense
>>  to add a feature to the most recent release branch, before the first actual
>>  release of that branch. These should be handled in the same way as bug fixes,
>> -that is, first implemented on master and then backported.
>> +that is, first implemented on main and then backported.
>>  
>>  Keep the authorship of a commit clear by maintaining a correct list of
>>  "Signed-off-by:"s. If a confusing situation comes up, as it occasionally does,
>> @@ -99,7 +99,7 @@ Pre-Push Hook
>>  -------------
>>  
>>  The following script can be helpful because it provides an extra
>> -chance to check for mistakes while pushing to the master branch of OVS
>> +chance to check for mistakes while pushing to the main branch of OVS
>>  or OVN.  If you would like to use it, install it as ``hooks/pre-push``
>>  in your ``.git`` directory and make sure to mark it as executable with
>>  ``chmod +x``.  For maximum utility, make sure ``checkpatch.py`` is in
>> @@ -118,7 +118,7 @@ in your ``.git`` directory and make sure to mark it as executable with
>>  
>>    while read local_ref local_sha1 remote_ref remote_sha1; do
>>        case $remote_ref in
>> -          refs/heads/master)
>> +          refs/heads/main)
>>                n=0
>>                while read sha
>>                do
>> diff --git a/Documentation/internals/contributing/backporting-patches.rst b/Documentation/internals/contributing/backporting-patches.rst
>> index 0ef7f5beb9b0..050daba23f3e 100644
>> --- a/Documentation/internals/contributing/backporting-patches.rst
>> +++ b/Documentation/internals/contributing/backporting-patches.rst
>> @@ -43,10 +43,10 @@ within Open vSwitch, but is broadly applied in the following fashion:
>>  - Maintainers backport changes from a development branch to release branches.
>>  
>>  With regards to Open vSwitch user space code and code that does not comprise
>> -the Linux datapath and compat code, the development branch is `master` in the
>> +the Linux datapath and compat code, the development branch is `main` in the
>>  Open vSwitch repository. Patches are applied first to this branch, then to the
>>  most recent `branch-X.Y`, then earlier `branch-X.Z`, and so on. The most common
>> -kind of patch in this category is a bugfix which affects master and other
>> +kind of patch in this category is a bugfix which affects main and other
>>  branches.
>>  
>>  For Linux datapath code, the primary development branch is in the `net-next`_
>> @@ -64,15 +64,15 @@ Changes to userspace components
>>  -------------------------------
>>  
>>  Patches which are fixing bugs should be considered for backporting from
>> -`master` to release branches. Open vSwitch contributors submit their patches
>> -targeted to the `master` branch, using the ``Fixes`` tag described in
>> -:doc:`submitting-patches`. The maintainer first applies the patch to `master`,
>> +`main` to release branches. Open vSwitch contributors submit their patches
>> +targeted to the `main` branch, using the ``Fixes`` tag described in
>> +:doc:`submitting-patches`. The maintainer first applies the patch to `main`,
>>  then backports the patch to each older affected tree, as far back as it goes or
>>  at least to all currently supported branches. This is usually each branch back
>>  to the oldest maintained LTS release branch or the last 4 release branches if
>>  the oldest LTS is newer.
>>  
>> -If the fix only affects a particular branch and not `master`, contributors
>> +If the fix only affects a particular branch and not `main`, contributors
>>  should submit the change with the target branch listed in the subject line of
>>  the patch. Contributors should list all versions that the bug affects. The
>>  ``git format-patch`` argument ``--subject-prefix`` may be used when posting the
>> diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst
>> index d939c2d3ab8b..f0c745dc6de0 100644
>> --- a/Documentation/internals/release-process.rst
>> +++ b/Documentation/internals/release-process.rst
>> @@ -34,33 +34,33 @@ or the #openvswitch IRC channel.
>>  Release Strategy
>>  ----------------
>>  
>> -Open vSwitch feature development takes place on the "master" branch.
>> -Ordinarily, new features are rebased against master and applied directly.  For
>> +Open vSwitch feature development takes place on the "main" branch.
>> +Ordinarily, new features are rebased against main and applied directly.  For
>>  features that take significant development, sometimes it is more appropriate to
>> -merge a separate branch into master; please discuss this on ovs-dev in advance.
>> +merge a separate branch into main; please discuss this on ovs-dev in advance.
>>  
>>  The process of making a release has the following stages.  See `Release
>>  Scheduling`_ for the timing of each stage:
>>  
>> -1. "Soft freeze" of the master branch.
>> +1. "Soft freeze" of the main branch.
>>  
>>     During the freeze, we ask committers to refrain from applying patches that
>>     add new features unless those patches were already being publicly discussed
>>     and reviewed before the freeze began.  Bug fixes are welcome at any time.
>>     Please propose and discuss exceptions on ovs-dev.
>>   
>> -2. Fork a release branch from master, named for the expected release number,
>> +2. Fork a release branch from main, named for the expected release number,
>>     e.g. "branch-2.3" for the branch that will yield Open vSwitch 2.3.x.
>>  
>>     Release branches are intended for testing and stabilization.  At this stage
>>     and in later stages, they should receive only bug fixes, not new features.
>>     Bug fixes applied to release branches should be backports of corresponding
>> -   bug fixes to the master branch, except for bugs present only on release
>> +   bug fixes to the main branch, except for bugs present only on release
>>     branches (which are rare in practice).
>>  
>>     At this stage, sometimes there can be exceptions to the rule that a release
>>     branch receives only bug fixes.  Like bug fixes, new features on release
>> -   branches should be backports of the corresponding commits on the master
>> +   branches should be backports of the corresponding commits on the main
>>     branch.  Features to be added to release branches should be limited in scope
>>     and risk and discussed on ovs-dev before creating the branch.
>>  
>> @@ -125,10 +125,10 @@ intermediate branches).
>>  Release Numbering
>>  -----------------
>>  
>> -The version number on master should normally end in .90.  This indicates that
>> +The version number on main should normally end in .90.  This indicates that
>>  the Open vSwitch version is "almost" the next version to branch.
>>  
>> -Forking master into branch-x.y requires two commits to master.  The first is
>> +Forking main into branch-x.y requires two commits to main.  The first is
>>  titled "Prepare for x.y.0" and increments the version number to x.y.  This is
>>  the initial commit on branch-x.y.  The second is titled "Prepare for post-x.y.0
>>  (x.y.90)" and increments the version number to x.y.90.
>> @@ -146,23 +146,23 @@ Release Scheduling
>>  Open vSwitch makes releases at the following six-month cadence.  All dates are
>>  approximate:
>>  
>> -+---------------+----------------+--------------------------------------+
>> -| Time (months) | Dates          | Stage                                |
>> -+---------------+----------------+--------------------------------------+
>> -| T             | Mar 1, Sep 1   | Begin x.y release cycle              |
>> -+---------------+----------------+--------------------------------------+
>> -| T + 4         | Jul 1, Jan 1   | "Soft freeze" master for x.y release |
>> -+---------------+----------------+--------------------------------------+
>> -| T + 4.5       | Jul 15, Jan 15 | Fork branch-x.y from master          |
>> -+---------------+----------------+--------------------------------------+
>> -| T + 5.5       | Aug 15, Feb 15 | Release version x.y.0                |
>> -+---------------+----------------+--------------------------------------+
>> ++---------------+----------------+------------------------------------+
>> +| Time (months) | Dates          | Stage                              |
>> ++---------------+----------------+------------------------------------+
>> +| T             | Mar 1, Sep 1   | Begin x.y release cycle            |
>> ++---------------+----------------+------------------------------------+
>> +| T + 4         | Jul 1, Jan 1   | "Soft freeze" main for x.y release |
>> ++---------------+----------------+------------------------------------+
>> +| T + 4.5       | Jul 15, Jan 15 | Fork branch-x.y from main          |
>> ++---------------+----------------+------------------------------------+
>> +| T + 5.5       | Aug 15, Feb 15 | Release version x.y.0              |
>> ++---------------+----------------+------------------------------------+
>>  
>>  How to Branch
>>  -------------
>>  
>> -To branch "master" for the eventual release of OVS version x.y.0,
>> -prepare two patches against master:
>> +To branch "main" for the eventual release of OVS version x.y.0,
>> +prepare two patches against main:
>>  
>>  1. "Prepare for x.y.0." following the model of commit 836d1973c56e
>>     ("Prepare for 2.11.0.").
>> @@ -172,12 +172,12 @@ prepare two patches against master:
>>  
>>  Post both patches to ovs-dev.  Get them reviewed in the usual way.
>>  
>> -Apply both patches to master, and create branch-x.y by pushing only
>> +Apply both patches to main, and create branch-x.y by pushing only
>>  the first patch.  The following command illustrates how to do both of
>>  these at once assuming the local repository HEAD points to the
>>  "Prepare for post-x.y.0" commit:
>>  
>> -        git push origin HEAD:master HEAD^:refs/heads/branch-x.y
>> +        git push origin HEAD:main HEAD^:refs/heads/branch-x.y
>>  
>>  Branching should be announced on ovs-dev.
>>  
>> @@ -200,7 +200,7 @@ Follow these steps to release version x.y.z of OVS from branch-x.y.
>>  
>>  4. Apply the patches to branch-x.y.
>>  
>> -5. If z = 0, apply the first patch (only) to master.
>> +5. If z = 0, apply the first patch (only) to main.
>>  
>>  6. Sign a tag vx.y.z "Open vSwitch version x.y.z" and push it to the
>>     repo.
>> diff --git a/Documentation/intro/install/dpdk.rst b/Documentation/intro/install/dpdk.rst
>> index c92e598d7ae8..f1646322c7e3 100644
>> --- a/Documentation/intro/install/dpdk.rst
>> +++ b/Documentation/intro/install/dpdk.rst
>> @@ -174,7 +174,7 @@ Additional information can be found in :doc:`general`.
>>    daemon will run as a non-root user.  This implies that you must have a
>>    working IOMMU.  Visit the `RHEL README`__ for additional information.
>>  
>> -__ https://github.com/openvswitch/ovs/blob/master/rhel/README.RHEL.rst
>> +__ https://github.com/openvswitch/ovs/blob/main/rhel/README.RHEL.rst
>>  
>>  
>>  Possible issues when enabling AVX512
>> diff --git a/Documentation/intro/install/fedora.rst b/Documentation/intro/install/fedora.rst
>> index 49fad844c7f7..f8a6bb6b6033 100644
>> --- a/Documentation/intro/install/fedora.rst
>> +++ b/Documentation/intro/install/fedora.rst
>> @@ -146,7 +146,7 @@ purpose.
>>  Refer to the `RHEL README`__ for additional usage and configuration
>>  information.
>>  
>> -__ https://github.com/openvswitch/ovs/blob/master/rhel/README.RHEL.rst
>> +__ https://github.com/openvswitch/ovs/blob/main/rhel/README.RHEL.rst
>>  
>>  Reporting Bugs
>>  --------------
>> diff --git a/Documentation/intro/install/general.rst b/Documentation/intro/install/general.rst
>> index 17c154268054..2b3959a14370 100644
>> --- a/Documentation/intro/install/general.rst
>> +++ b/Documentation/intro/install/general.rst
>> @@ -37,7 +37,7 @@ repository, which you can clone into a directory named "ovs" with::
>>  
>>      $ git clone https://github.com/openvswitch/ovs.git
>>  
>> -Cloning the repository leaves the "master" branch initially checked
>> +Cloning the repository leaves the "main" branch initially checked
>>  out.  This is the right branch for general development.  If, on the
>>  other hand, if you want to build a particular released version, you
>>  can check it out by running a command such as the following from the
>> diff --git a/Documentation/intro/install/rhel.rst b/Documentation/intro/install/rhel.rst
>> index f2151d890717..e442fca0c0ed 100644
>> --- a/Documentation/intro/install/rhel.rst
>> +++ b/Documentation/intro/install/rhel.rst
>> @@ -211,7 +211,7 @@ implemented.  Refer to `README.RHEL.rst`__ in the source tree or
>>  /usr/share/doc/openvswitch/README.RHEL.rst in the installed openvswitch package
>>  for details.
>>  
>> -__ https://github.com/openvswitch/ovs/blob/master/rhel/README.RHEL.rst
>> +__ https://github.com/openvswitch/ovs/blob/main/rhel/README.RHEL.rst
>>  
>>  Reporting Bugs
>>  --------------
>> diff --git a/Documentation/topics/language-bindings.rst b/Documentation/topics/language-bindings.rst
>> index 414f7c73fa38..15958d76da93 100644
>> --- a/Documentation/topics/language-bindings.rst
>> +++ b/Documentation/topics/language-bindings.rst
>> @@ -49,7 +49,7 @@ required dependencies, run:
>>  
>>  or install `python3-netaddr` and `python3-pyparsing`.
>>  
>> -__ https://github.com/openvswitch/ovs/tree/master/python/ovs
>> +__ https://github.com/openvswitch/ovs/tree/main/python/ovs
>>  
>>  Third-Party Bindings
>>  --------------------
>> diff --git a/Documentation/tutorials/faucet.rst b/Documentation/tutorials/faucet.rst
>> index 6aa4d39aa8ab..33e4543e4023 100644
>> --- a/Documentation/tutorials/faucet.rst
>> +++ b/Documentation/tutorials/faucet.rst
>> @@ -27,7 +27,7 @@ OVS Faucet Tutorial
>>  
>>  This tutorial demonstrates how Open vSwitch works with a general-purpose
>>  OpenFlow controller, using the Faucet controller as a simple way to get
>> -started.  It was tested with the "master" branch of Open vSwitch and version
>> +started.  It was tested with the "main" branch of Open vSwitch and version
>>  1.6.15 of Faucet.  It does not use advanced or recently added features in OVS
>>  or Faucet, so other versions of both pieces of software are likely to work
>>  equally well.
>> @@ -68,7 +68,7 @@ approaches:
>>       $ git clone https://github.com/openvswitch/ovs.git
>>       $ cd ovs
>>  
>> -   The default checkout is the master branch.  You will need to use the master
>> +   The default checkout is the main branch.  You will need to use the main
>>     branch for this tutorial as it includes some functionality required for this
>>     tutorial.
>>  
>> @@ -84,7 +84,7 @@ approaches:
>>  
>>       The default behaviour for some of the commands used in this tutorial
>>       changed in Open vSwitch versions 2.9.x and 2.10.x which breaks the
>> -     tutorial.  We recommend following step 3 and building master from
>> +     tutorial.  We recommend following step 3 and building main from
>>       source or using a system Open vSwitch that is version 2.8.x or older.
>>  
>>     If it is successful, you will find yourself in a subshell environment, which
>> diff --git a/Documentation/tutorials/ovs-conntrack.rst b/Documentation/tutorials/ovs-conntrack.rst
>> index e8a58c4eb298..6b0b73cd1173 100644
>> --- a/Documentation/tutorials/ovs-conntrack.rst
>> +++ b/Documentation/tutorials/ovs-conntrack.rst
>> @@ -35,7 +35,7 @@ to match on the TCP segments from connection setup to connection tear down.
>>  It will use OVS with the Linux kernel module as the datapath for this
>>  tutorial. (The datapath that utilizes the openvswitch kernel module to do
>>  the packet processing in the Linux kernel)
>> -It was tested with the "master" branch of Open vSwitch.
>> +It was tested with the "main" branch of Open vSwitch.
>>  
>>  Definitions
>>  -----------
>> diff --git a/NEWS b/NEWS
>> index c9e4064e67a7..9c3e59455d29 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -4,7 +4,9 @@ Post-v3.3.0
>>       * Conntrack now supports 'random' flag for selecting ports in a range
>>         while natting and 'persistent' flag for selection of the IP address
>>         from a range.
>> -
> 
> Please, keep two empty lines between sections for different releases.
> 
>> +  - The primary development branch has been renamed from 'master' to 'main'.
>> +    The OVS tree remains hosted on GitHub.
>> +    https://github.com/openvswitch/ovs.git
>>  
>>  v3.3.0 - 16 Feb 2024
>>  --------------------
>> diff --git a/README.rst b/README.rst
>> index a2c234f4d17c..ca9e386c2069 100644
>> --- a/README.rst
>> +++ b/README.rst
>> @@ -8,7 +8,7 @@ Open vSwitch
>>  
>>  .. image:: https://github.com/openvswitch/ovs/workflows/Build%20and%20Test/badge.svg
>>      :target: https://github.com/openvswitch/ovs/actions
>> -.. image:: https://ci.appveyor.com/api/projects/status/github/openvswitch/ovs?branch=master&svg=true&retina=true
>> +.. image:: https://ci.appveyor.com/api/projects/status/github/openvswitch/ovs?branch=main&svg=true&retina=true
>>      :target: https://ci.appveyor.com/project/blp/ovs/history
>>  .. image:: https://api.cirrus-ci.com/github/openvswitch/ovs.svg
>>      :target: https://cirrus-ci.com/github/openvswitch/ovs
>> diff --git a/appveyor.yml b/appveyor.yml
>> index 29cc44d6c6f6..65e29eb4e3be 100644
>> --- a/appveyor.yml
>> +++ b/appveyor.yml
>> @@ -2,7 +2,7 @@ version: 1.0.{build}
>>  image: Visual Studio 2019
>>  branches:
>>    only:
>> -  - master
>> +  - main
> 
> Should be done in two stages as described above.
> 
>>  configuration:
>>    - Debug
>>    - Release
>> @@ -23,7 +23,7 @@ install:
>>      New-Item -ItemType Directory -Force -Path C:\ovs-build-downloads
>>  
>>      # Find and download the latest stable OpenSSl 3.0.
>> -    $URL = "https://raw.githubusercontent.com/slproweb/opensslhashes/master/win32_openssl_hashes.json"
>> +    $URL = "https://raw.githubusercontent.com/slproweb/opensslhashes/main/win32_openssl_hashes.json"
> 
> As mentioned in the other email, this is not a correct change
> as it is not our repo.
> 
>>      $webData = (Invoke-WebRequest -Uri $URL).content | ConvertFrom-Json
>>      $source = ($webData.files.PSObject.Properties | Where-Object {
>>          $_.Value.basever   -match "3.0.*" -and
>> @@ -74,6 +74,6 @@ build_script:
>>           c:\OpenvSwitch-$env:CONFIGURATION.msi
>>  
>>  after_build:
>> -- ps: 7z a C:\ovs-master-$env:CONFIGURATION.zip C:\openvswitch
>> -- ps: Push-AppveyorArtifact C:\ovs-master-$env:CONFIGURATION.zip
>> +- ps: 7z a C:\ovs-main-$env:CONFIGURATION.zip C:\openvswitch
>> +- ps: Push-AppveyorArtifact C:\ovs-main-$env:CONFIGURATION.zip
>>  - ps: Push-AppveyorArtifact C:\OpenvSwitch-$env:CONFIGURATION.msi
>>
> 
> Best regards, Ilya Maximets.
>

Hi,

On 3/21/24 6:09 AM, Simon Horman wrote:
> Recently OVS adopted a policy of using the inclusive naming word list v1
> [1, 2].
> 
> In keeping with this policy rename the primary development branch from
> 'master' to 'main'. This patch does not actually make that change,
> but rather updates references to the branch in the source tree.
> It is intended to be applied at (approximately) the same time that the
> change is made.
> 
> OVS is currently hosted on GitHub. We can expect the following behaviour
> after the rename:

I don't think this will break Openstack Neutron as all our jobs use a 
specific OVS hash from what I can see. Thanks for the heads-up.

-Brian

On Thu, Mar 21, 2024 at 01:32:39PM +0100, Ilya Maximets wrote:
> CC: ovs-discuss for visibility.
> 
> It seems like this change will affect ovn-fake-multinode project
> and ovn-heater as they are cloning 'master' branch by default.
> Also the OVN project itself is cloning OVS master branch in one
> of the CI workflows.

Hi Ilya,

thanks for your review and increasing visibility of this change.

> On 3/21/24 11:09, Simon Horman wrote:
> > Recently OVS adopted a policy of using the inclusive naming word list v1
> > [1, 2].
> > 
> > In keeping with this policy rename the primary development branch from
> > 'master' to 'main'. This patch does not actually make that change,
> > but rather updates references to the branch in the source tree.
> > It is intended to be applied at (approximately) the same time that the
> > change is made.
> > 
> > OVS is currently hosted on GitHub. We can expect the following behaviour
> > after the rename:
> > 
> > 1. GitHub pull requests against are renamed branch are automatically
> >    re-homed on new branch
> > 2. GitHub Issues do not seem to be affected - at least the test issue I
> >    created had no association with a branch
> > 3. URLs accessed via the GitHub web UI are automatically renamed
> >    (so long as a new branch called master is not created).
> > 4. Using the git cli command, fetch will fetch the new branch (main),
> >    and fetch -p will remove (prune) the old branch (master)
> 
> We may want to mention that users will need to update their .git/config
> to point their checked out branches to the new upstream branch.  I don't
> think git will do that automatically.

I'll experiment with git a bit and see if I can come up with
some guidance wrt this.

> > [1] df5e5cf ("Documentation: Add section on inclusive language.")
> > [2] https://inclusivenaming.org/word-lists/
> > 
> > Signed-off-by: Simon Horman <horms@ovn.org>
> > ---
> > Notes:
> > 
> > * Now is the time to raise any concerns regarding this patch.
> >   I plan to repost in approximately a week.
> >   And implement the change another week after that.
> > 
> > * If you have an automation that fetches the master branch then
> >   the suggested action is:
> >   1. Before the branch rename occurs: update the automation to pull main an
> >      fall back to pulling master if that fails
> >   2. After the rename occurs: Update the automation to only fetch main
> > 
> > * The appveyor change is atomic, I'm open to suggestions on this.
> >   Also, I am unsure how to test this change.
> 
> While most of the changes in this patch are inconsequential, i.e. will
> not break anything when applied, the AppVeyor change will break CI.
> 
> So, we should not make the change in atomic fashion.  I suggest we add
> (not replace!) the 'main' to the list of branches in the appveyor.yml
> as a separate patch.  This patch will need to be applied *before*
> renaming the branch.  It should be fine to apply it even a few days or
> a week before the change is made.  Then the rest of the changes in this
> patch should be applied *after* the branch is re-named.
> 
> This should ensure the continuity of CI for AppVeyor.  This is basically
> the same thing as described in 'If you have an automation' section, but
> applied to our own in-tree CI.
> 
> For the testing, you can install AppVeyor to your own private fork.
> See https://www.appveyor.com/docs/ .

Understood, I'll see about breaking out this change.

> Couple small comments inline.

...

> > diff --git a/NEWS b/NEWS
> > index c9e4064e67a7..9c3e59455d29 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -4,7 +4,9 @@ Post-v3.3.0
> >       * Conntrack now supports 'random' flag for selecting ports in a range
> >         while natting and 'persistent' flag for selection of the IP address
> >         from a range.
> > -
> 
> Please, keep two empty lines between sections for different releases.

Ack, will do.

...

> > diff --git a/appveyor.yml b/appveyor.yml
> > index 29cc44d6c6f6..65e29eb4e3be 100644
> > --- a/appveyor.yml
> > +++ b/appveyor.yml
> > @@ -2,7 +2,7 @@ version: 1.0.{build}
> >  image: Visual Studio 2019
> >  branches:
> >    only:
> > -  - master
> > +  - main
> 
> Should be done in two stages as described above.

Thanks, assuming I can do something like:

branches:
  only:
  - master
  - main

> 
> >  configuration:
> >    - Debug
> >    - Release
> > @@ -23,7 +23,7 @@ install:
> >      New-Item -ItemType Directory -Force -Path C:\ovs-build-downloads
> >  
> >      # Find and download the latest stable OpenSSl 3.0.
> > -    $URL = "https://raw.githubusercontent.com/slproweb/opensslhashes/master/win32_openssl_hashes.json"
> > +    $URL = "https://raw.githubusercontent.com/slproweb/opensslhashes/main/win32_openssl_hashes.json"
> 
> As mentioned in the other email, this is not a correct change
> as it is not our repo.

Yes, I'll drop this hunk.

> >      $webData = (Invoke-WebRequest -Uri $URL).content | ConvertFrom-Json
> >      $source = ($webData.files.PSObject.Properties | Where-Object {
> >          $_.Value.basever   -match "3.0.*" -and

...