scripts/checkpatch.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Some maintainers prefer to allow duplicate signatures if that provides
additional details about the patch flow. E.g. if the original patch
author pulls the patch from the patchwork into the kernel branch, this
can result in duplicate SOB tags from him, however this reflects the
patch flow (one SOB for being the author, one SOB for pulling the patch,
adding (and maybe fixing) tags and pushing the patch further.
To facilitate easily handling this kind of warnings, separate duplicate
SOBs into the separate warning class ('DUPLICATE_SIGN_OFF').
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 79e759aac543..f95d4ac19901 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3115,7 +3115,7 @@ sub process {
$sig_nospace =~ s/\s//g;
$sig_nospace = lc($sig_nospace);
if (defined $signatures{$sig_nospace}) {
- WARN("BAD_SIGN_OFF",
+ WARN("DUPLICATE_SIGN_OFF",
"Duplicate signature\n" . $herecurr);
} else {
$signatures{$sig_nospace} = 1;
--
2.35.1
On Mon, 2022-09-05 at 13:45 +0300, Dmitry Baryshkov wrote:
> Some maintainers prefer to allow duplicate signatures if that provides
> additional details about the patch flow. E.g. if the original patch
> author pulls the patch from the patchwork into the kernel branch, this
> can result in duplicate SOB tags from him, however this reflects the
> patch flow (one SOB for being the author, one SOB for pulling the patch,
> adding (and maybe fixing) tags and pushing the patch further.
I think that's poor process, but whatever...
>
> To facilitate easily handling this kind of warnings, separate duplicate
> SOBs into the separate warning class ('DUPLICATE_SIGN_OFF').
>
> Cc: Rob Clark <robdclark@gmail.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> scripts/checkpatch.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 79e759aac543..f95d4ac19901 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3115,7 +3115,7 @@ sub process {
> $sig_nospace =~ s/\s//g;
> $sig_nospace = lc($sig_nospace);
> if (defined $signatures{$sig_nospace}) {
> - WARN("BAD_SIGN_OFF",
> + WARN("DUPLICATE_SIGN_OFF",
> "Duplicate signature\n" . $herecurr);
> } else {
> $signatures{$sig_nospace} = 1;
On Mon, 5 Sept 2022 at 16:59, Joe Perches <joe@perches.com> wrote:
>
> On Mon, 2022-09-05 at 13:45 +0300, Dmitry Baryshkov wrote:
> > Some maintainers prefer to allow duplicate signatures if that provides
> > additional details about the patch flow. E.g. if the original patch
> > author pulls the patch from the patchwork into the kernel branch, this
> > can result in duplicate SOB tags from him, however this reflects the
> > patch flow (one SOB for being the author, one SOB for pulling the patch,
> > adding (and maybe fixing) tags and pushing the patch further.
>
> I think that's poor process, but whatever...
Gracious ping. We'd like to ask to get this in or to understand how to
properly handle/modify our process.
Thank you.
>
> >
> > To facilitate easily handling this kind of warnings, separate duplicate
> > SOBs into the separate warning class ('DUPLICATE_SIGN_OFF').
> >
> > Cc: Rob Clark <robdclark@gmail.com>
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > ---
> > scripts/checkpatch.pl | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 79e759aac543..f95d4ac19901 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -3115,7 +3115,7 @@ sub process {
> > $sig_nospace =~ s/\s//g;
> > $sig_nospace = lc($sig_nospace);
> > if (defined $signatures{$sig_nospace}) {
> > - WARN("BAD_SIGN_OFF",
> > + WARN("DUPLICATE_SIGN_OFF",
> > "Duplicate signature\n" . $herecurr);
> > } else {
> > $signatures{$sig_nospace} = 1;
>
--
With best wishes
Dmitry
© 2016 - 2026 Red Hat, Inc.