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