Simon Horman <[email protected]> writes: > 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] df5e5cf4318a ("Documentation: Add section on inclusive language.") > [2] https://inclusivenaming.org/word-lists/ > > Signed-off-by: Simon Horman <[email protected]> > --- > Changes in v2: > - Keep two blank lines between versions. > - Drop bogus update to OpenSSL hashes URL in appveyor.yml. > - Drop other appveyor.yml changes, they are now present upstream. > + appveyor: Prepare for rename of primary development branch. > https://github.com/openvswitch/ovs/commit/95ff912edef8 > - Add note about updates to git configuration. > --- > Notes: > > * Now is the time to raise any concerns regarding this patch. > It is planned to implement this change next week.
Awesome! > * 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 > > * After the change it may be necessary to update your local > git configuration for checked out branches. > > For example: > # Fetch origin: new remote main branch; remote master branch is deleted > git fetch -tp origin > # Rename local branch > git branch -m master main > # Update local main branch to use remote main branch as it's upstream > git branch --set-upstream-to=origin/main main Thanks for listing these steps. Hopefully it will make it simpler for others. > --- > .../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 | 3 ++ > README.rst | 2 +- > 12 files changed, 50 insertions(+), 47 deletions(-) Acked-by: Aaron Conole <[email protected]> > 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 04bb0fc350fd..2007a429c7bc 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`_ > @@ -67,15 +67,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..5c9fff54595c 100644 > --- a/NEWS > +++ b/NEWS > @@ -4,6 +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. > + - 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 > > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
