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