[dpdk-dev] [PATCH] switch default git branch name to main

[dpdk-dev] [PATCH] switch default git branch name to main

[Thomas Monjalon]

The default git branch of the main DPDK repository has been renamed
from master to main.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
 devtools/check-git-log.sh           | 4 ++--
 devtools/checkpatches.sh            | 4 ++--
 doc/guides/contributing/patches.rst | 5 +++--
 doc/guides/contributing/stable.rst  | 6 +++---
 4 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/devtools/check-git-log.sh b/devtools/check-git-log.sh
index 08fea5d9b7..9988bf863d 100755
--- a/devtools/check-git-log.sh
+++ b/devtools/check-git-log.sh
@@ -16,7 +16,7 @@ print_usage () {
 	by latest git commits limited with -n option, or commits in the git
 	range specified with -r option.
 	e.g. To check only the last commit, ‘-n1’ or ‘-r@~..’ is used.
-	If no range provided, default is origin/master..HEAD.
+	If no range provided, default is origin/main..HEAD.
 	END_OF_HELP
 }
 
@@ -27,7 +27,7 @@ selfdir=$(dirname $(readlink -f $0))
 # and allows for specifying the patches to check by passing -nX or -r range.
 # The old format allows for specifying patches by passing -X or range
 # as the first argument.
-range=${1:-origin/master..}
+range=${1:-origin/main..}
 
 if [ "$range" = '--help' ] ; then
 	print_usage
diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
index b5191df08f..78a408ef98 100755
--- a/devtools/checkpatches.sh
+++ b/devtools/checkpatches.sh
@@ -45,7 +45,7 @@ print_usage () {
 
 	The patches to check can be from stdin, files specified on the command line,
 	latest git commits limited with -n option, or commits in the git range
-	specified with -r option (default: "origin/master..").
+	specified with -r option (default: "origin/main..").
 	END_OF_HELP
 }
 
@@ -200,7 +200,7 @@ check_internal_tags() { # <patch>
 }
 
 number=0
-range='origin/master..'
+range='origin/main..'
 quiet=false
 verbose=false
 while getopts hn:qr:v ARG ; do
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index de493a901d..425bb874f8 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -118,7 +118,8 @@ The proposer should justify the need for a new sub-tree and should have demonstr
 The maintainer should be confirmed by an ``ack`` from an existing tree maintainer.
 Disagreements on trees or maintainers can be brought to the Technical Board.
 
-The backup maintainer for the master tree should be selected from the existing sub-tree maintainers from the project.
+The backup maintainer for the main tree should be selected
+from the existing sub-tree maintainers of the project.
 The backup maintainer for a sub-tree should be selected from among the component maintainers within that sub-tree.
 
 
@@ -319,7 +320,7 @@ For example::
 Patch for Stable Releases
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-All fix patches to the master branch that are candidates for backporting
+All fix patches to the main branch that are candidates for backporting
 should also be CCed to the `stable@dpdk.org <https://mails.dpdk.org/listinfo/stable>`_
 mailing list.
 In the commit message body the Cc: stable@dpdk.org should be inserted as follows::
diff --git a/doc/guides/contributing/stable.rst b/doc/guides/contributing/stable.rst
index 890bbeccc3..75e71951b1 100644
--- a/doc/guides/contributing/stable.rst
+++ b/doc/guides/contributing/stable.rst
@@ -28,7 +28,7 @@ Stable Releases
 Any release of DPDK can be designated as a Stable Release if a
 maintainer volunteers to maintain it and there is a commitment from major
 contributors to validate it before releases. If a release is to be designated
-as a Stable Release, it should be done by 1 month after the master release.
+as a Stable Release, it should be done by 1 month after the main release.
 
 A Stable Release is used to backport fixes from an ``N`` release back to an
 ``N-1`` release, for example, from 16.11 to 16.07.
@@ -72,7 +72,7 @@ point the LTS branch will no longer be maintained with no further releases.
 What changes should be backported
 ---------------------------------
 
-Backporting should be limited to bug fixes. All patches accepted on the master
+Backporting should be limited to bug fixes. All patches accepted on the main
 branch with a Fixes: tag should be backported to the relevant stable/LTS
 branches, unless the submitter indicates otherwise. If there are exceptions,
 they will be discussed on the mailing lists.
@@ -107,7 +107,7 @@ The Stable Mailing List
 The Stable and LTS release are coordinated on the stable@dpdk.org mailing
 list.
 
-All fix patches to the master branch that are candidates for backporting
+All fix patches to the main branch that are candidates for backporting
 should also be CCed to the `stable@dpdk.org <https://mails.dpdk.org/listinfo/stable>`_
 mailing list.
 
-- 
2.27.0

Re: [dpdk-dev] [PATCH] switch default git branch name to main

[Bruce Richardson]

On Wed, Aug 12, 2020 at 11:29:15AM +0200, Thomas Monjalon wrote:
> The default git branch of the main DPDK repository has been renamed
> from master to main.
> 
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
>  devtools/check-git-log.sh           | 4 ++--
>  devtools/checkpatches.sh            | 4 ++--
>  doc/guides/contributing/patches.rst | 5 +++--
>  doc/guides/contributing/stable.rst  | 6 +++---
>  4 files changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/devtools/check-git-log.sh b/devtools/check-git-log.sh
> index 08fea5d9b7..9988bf863d 100755
> --- a/devtools/check-git-log.sh
> +++ b/devtools/check-git-log.sh
> @@ -16,7 +16,7 @@ print_usage () {
>  	by latest git commits limited with -n option, or commits in the git
>  	range specified with -r option.
>  	e.g. To check only the last commit, ‘-n1’ or ‘-r@~..’ is used.
> -	If no range provided, default is origin/master..HEAD.
> +	If no range provided, default is origin/main..HEAD.
>  	END_OF_HELP
>  }
>  
> @@ -27,7 +27,7 @@ selfdir=$(dirname $(readlink -f $0))
>  # and allows for specifying the patches to check by passing -nX or -r range.
>  # The old format allows for specifying patches by passing -X or range
>  # as the first argument.
> -range=${1:-origin/master..}
> +range=${1:-origin/main..}
>  
>  if [ "$range" = '--help' ] ; then
>  	print_usage
> diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
> index b5191df08f..78a408ef98 100755
> --- a/devtools/checkpatches.sh
> +++ b/devtools/checkpatches.sh
> @@ -45,7 +45,7 @@ print_usage () {
>  
>  	The patches to check can be from stdin, files specified on the command line,
>  	latest git commits limited with -n option, or commits in the git range
> -	specified with -r option (default: "origin/master..").
> +	specified with -r option (default: "origin/main..").
>  	END_OF_HELP
>  }
>  
> @@ -200,7 +200,7 @@ check_internal_tags() { # <patch>
>  }
>  
>  number=0
> -range='origin/master..'
> +range='origin/main..'
>  quiet=false
>  verbose=false
>  while getopts hn:qr:v ARG ; do
> diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
> index de493a901d..425bb874f8 100644
> --- a/doc/guides/contributing/patches.rst
> +++ b/doc/guides/contributing/patches.rst
> @@ -118,7 +118,8 @@ The proposer should justify the need for a new sub-tree and should have demonstr
>  The maintainer should be confirmed by an ``ack`` from an existing tree maintainer.
>  Disagreements on trees or maintainers can be brought to the Technical Board.
>  
> -The backup maintainer for the master tree should be selected from the existing sub-tree maintainers from the project.
> +The backup maintainer for the main tree should be selected
> +from the existing sub-tree maintainers of the project.
>  The backup maintainer for a sub-tree should be selected from among the component maintainers within that sub-tree.
>  

This does not need to be a straight master -> main replacement. I wonder if
"release tree" would be a better name. However, "main" is probably clear
enough, so I'm ok to keep this as suggested here.

>  
> @@ -319,7 +320,7 @@ For example::
>  Patch for Stable Releases
>  ~~~~~~~~~~~~~~~~~~~~~~~~~
>  
> -All fix patches to the master branch that are candidates for backporting
> +All fix patches to the main branch that are candidates for backporting
>  should also be CCed to the `stable@dpdk.org <https://mails.dpdk.org/listinfo/stable>`_
>  mailing list.
>  In the commit message body the Cc: stable@dpdk.org should be inserted as follows::
> diff --git a/doc/guides/contributing/stable.rst b/doc/guides/contributing/stable.rst
> index 890bbeccc3..75e71951b1 100644
> --- a/doc/guides/contributing/stable.rst
> +++ b/doc/guides/contributing/stable.rst
> @@ -28,7 +28,7 @@ Stable Releases
>  Any release of DPDK can be designated as a Stable Release if a
>  maintainer volunteers to maintain it and there is a commitment from major
>  contributors to validate it before releases. If a release is to be designated
> -as a Stable Release, it should be done by 1 month after the master release.
> +as a Stable Release, it should be done by 1 month after the main release.

Not sure if this the most readable. The term "release" might be better
replaced with "version" to allow the use of "release" as a verb for
readability.

"Any release version of DPDK can be designated a Stable Release if ...
If a version is to be a "Stable Release", it should be designated as such
within one month of that version being initially released"

>  
>  A Stable Release is used to backport fixes from an ``N`` release back to an
>  ``N-1`` release, for example, from 16.11 to 16.07.
> @@ -72,7 +72,7 @@ point the LTS branch will no longer be maintained with no further releases.
>  What changes should be backported
>  ---------------------------------
>  
> -Backporting should be limited to bug fixes. All patches accepted on the master
> +Backporting should be limited to bug fixes. All patches accepted on the main
>  branch with a Fixes: tag should be backported to the relevant stable/LTS
>  branches, unless the submitter indicates otherwise. If there are exceptions,
>  they will be discussed on the mailing lists.
> @@ -107,7 +107,7 @@ The Stable Mailing List
>  The Stable and LTS release are coordinated on the stable@dpdk.org mailing
>  list.
>  
> -All fix patches to the master branch that are candidates for backporting
> +All fix patches to the main branch that are candidates for backporting
>  should also be CCed to the `stable@dpdk.org <https://mails.dpdk.org/listinfo/stable>`_
>  mailing list.
>  
> -- 
> 2.27.0
> 

As-is or with above suggestions, this seems fine.

Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Re: [dpdk-dev] [PATCH] switch default git branch name to main

[Thomas Monjalon]

12/08/2020 14:47, Bruce Richardson:
> On Wed, Aug 12, 2020 at 11:29:15AM +0200, Thomas Monjalon wrote:
> > The default git branch of the main DPDK repository has been renamed
> > from master to main.
> > 
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
[...]
> > -The backup maintainer for the master tree should be selected from the existing sub-tree maintainers from the project.
> > +The backup maintainer for the main tree should be selected
> > +from the existing sub-tree maintainers of the project.
> 
> This does not need to be a straight master -> main replacement. I wonder if
> "release tree" would be a better name. However, "main" is probably clear
> enough, so I'm ok to keep this as suggested here.

"release tree" does not distinguish from stable releases.
I agree "main" is not ideal to identify the tree,
but I don't see any better wording.

[...]
> >  Any release of DPDK can be designated as a Stable Release if a
> >  maintainer volunteers to maintain it and there is a commitment from major
> >  contributors to validate it before releases. If a release is to be designated
> > -as a Stable Release, it should be done by 1 month after the master release.
> > +as a Stable Release, it should be done by 1 month after the main release.
> 
> Not sure if this the most readable. The term "release" might be better
> replaced with "version" to allow the use of "release" as a verb for
> readability.
> 
> "Any release version of DPDK can be designated a Stable Release if ...
> If a version is to be a "Stable Release", it should be designated as such
> within one month of that version being initially released"

You wording is a lot better. I take it, thanks.

> As-is or with above suggestions, this seems fine.
> 
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Applied with last suggestion, thanks