OVN hasn't used the name "master" for quite a while, and it looks like we missed some documents when the change to "main" was made.
Signed-off-by: Mark Michelson <[email protected]> --- .../internals/committer-grant-revocation.rst | 2 +- .../internals/committer-responsibilities.rst | 8 ++++---- .../internals/contributing/backporting-patches.rst | 12 ++++++------ 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/Documentation/internals/committer-grant-revocation.rst b/Documentation/internals/committer-grant-revocation.rst index 49c7769b8..d2c0e0447 100644 --- a/Documentation/internals/committer-grant-revocation.rst +++ b/Documentation/internals/committer-grant-revocation.rst @@ -26,7 +26,7 @@ OVN Committer Grant/Revocation Policy ===================================== An OVN committer is a participant in the project with the ability to commit -code directly to the master repository. Commit access grants a broad ability to +code directly to the main repository. Commit access grants a broad ability to affect the progress of the project as presented by its most important artifact, the code and related resources that produce working binaries of OVN As such it represents a significant level of trust in an individual's diff --git a/Documentation/internals/committer-responsibilities.rst b/Documentation/internals/committer-responsibilities.rst index 1280076ad..40c1e737a 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, diff --git a/Documentation/internals/contributing/backporting-patches.rst b/Documentation/internals/contributing/backporting-patches.rst index fbc200bfc..711a8e36b 100644 --- a/Documentation/internals/contributing/backporting-patches.rst +++ b/Documentation/internals/contributing/backporting-patches.rst @@ -43,24 +43,24 @@ within OVN, but is broadly applied in the following fashion: - Maintainers backport changes from a development branch to release branches. With regards to OVN 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 OVN 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. Changes to userspace components ------------------------------- Patches which are fixing bugs should be considered for backporting from -`master` to release branches. OVN 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. OVN 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 most recent LTS release branch. -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 -- 2.39.2 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
