Re: [ovs-discuss] [ovs-dev] [PATCH] Rename primary development branch as main.
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
> > ---
> > 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 | W
Re: [ovs-discuss] [ovs-dev] [PATCH] Rename primary development branch as main.
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
>> ---
>> 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/inte
Re: [ovs-discuss] [ovs-dev] [PATCH] Rename primary development branch as main.
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
> ---
> 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
