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 <ho...@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. > _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
