[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKXUXMyOk+06ZRc7gvYMA=KHvZZp1FXiCJC5Tp9M=SUQfQnBVQ@mail.gmail.com>
Date: Mon, 23 Oct 2023 16:16:55 +0200
From: Lukas Bulwahn <lukas.bulwahn@...il.com>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: Andy Whitcroft <apw@...onical.com>, Joe Perches <joe@...ches.com>,
Dwaipayan Ray <dwaipayanray1@...il.com>,
Sean Christopherson <seanjc@...gle.com>,
workflows@...r.kernel.org, linux-kernel@...r.kernel.org,
Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
Jacob Keller <jacob.e.keller@...el.com>
Subject: Re: [PATCH] checkpatch: allow tags between co-developed-by and their sign-off
Hi Przemek,
On Mon, Oct 23, 2023 at 12:29 PM Przemek Kitszel
<przemyslaw.kitszel@...el.com> wrote:
>
> Allow additional tags between Co-developed-by: and Signed-off-by:.
>
> Removing the "immediately" word from the doc is a great summary of the
> change - there is no need for the two tags to be glued together, barring
> ease of checkpatch implementation.
>
I think the currently suggested process of keeping Co-developed-by and
Signed-off-by glued together is good, and I see no reason why this
should be changed, nor do I see any drawbacks.
> Additional tags between Co-developed-by and corresponding Signed-off-by
> could include Reviewed-by tags collected by Submitter, which is also
> a Co-developer, but should sign-off at the very end of tags provided by
> the Submitter.
>
The other tags, Reviewed-by, etc., can go anywhere just not between
Co-developed-by and corresponding Signed-off-by. So, why do you have
this need to put it exactly there rather than putting it anywhere
else?
The commit message tells me what you are proposing, but there is no
rationale in the commit message and that is put up for discussion here
with the proposed change.
I see many potential areas of work for the checkpatch script, but in
my humble opinion, this really is not one of the rules that needs to
be improved.
Lukas
(...snipped the rest...)
Powered by blists - more mailing lists