[RFC PATCH 0/1] Attempt to add Sponsored-by tag

[RFC PATCH 0/1] Attempt to add Sponsored-by tag

[Giulio Benetti]

Hello All,

working as a consultant for some companies it happens to end up in having
patches that the final customer could be reluctant to send upstream for
many reasons. One of these reason is that at the moment he would not gain
visibility except being added in the commit log as Cc: as far as I know.

What I've been pointed to by someone is "Sponsored by:" that is not a real
tag and it's been used not that often, for example here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73c289bac05919286f8c7e1660fcaf6ec0468363
And as you know better than me:
$ git log --grep="Sponsored by:"

As explained in the commit log of the patch this is an attempt to define a
standard Sponsored-by: tag including a method of acknowledge on sponsor's side.
The goal is to possibly increase upstreamed patches giving the chance to the
sponsors to gain visibility.

I hope someone likes the idea and that someone could help me to improve the
description in the patch because I'm not an English mother language.

Best regards
--
Giulio Benetti
CEO&CTO@Benetti Engineering sas

Giulio Benetti (1):
  docs: submitting-patches: Add Sponsored-by tag to give credits to who
    sponsored the patch

 Documentation/process/submitting-patches.rst | 38 ++++++++++++++++++++
 1 file changed, 38 insertions(+)

-- 
2.34.1

[RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Giulio Benetti]

Sometimes it happens that a Company or a Physical Person sponsors the
creation and/or the upstreaming process of a patch, but at the moment
there is no way to give credits to it. There are some commit that include
a sort of tag "Sponsored by" without the dash to avoid
scripts/checkpatch.pl to complain but a real standard has not been defined.
With this patch let's try to define a method to give credits consistently
including an acknowledge from the sponsor. The goal is to improve
contributions from companies or physical persons that this way should gain
visibility in Linux kernel and so they should be more prone to let the
work done for them for to be upstreamed.

Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
---
 Documentation/process/submitting-patches.rst | 38 ++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index efac910e2659..870e6b5def3f 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -600,6 +600,44 @@ process nor the requirement to Cc: stable@vger.kernel.org on all stable
 patch candidates. For more information, please read
 Documentation/process/stable-kernel-rules.rst.
 
+Using Sponsored-by:
+-------------------
+
+A Sponsored-by tag gives credit to who sponsored the creation and/or the
+upstreaming process of the patch. Sponsored-by can contain a company name or
+a physical person name. If a company sponsored the patch this is the form::
+
+	Company Name <mail@companyname.com>
+
+where the Company Name must be a valid Business Name at the time of sending the
+patch until the confirmation of the Sponsored-by tag, while the e-mail can be
+either a generic e-mail the company can be reached out or an e-mail of a person
+who has the rights inside it to confirm the Sponsored-by tag.
+
+If a physical person sponsored the patch the form must be same used in
+Signed-off-by tag::
+
+	Physical Person <physical.person@mail.com>
+
+In both cases, to prevent fake credits, either the company or the person should
+send an Acked-by tag placed right under Sponsored-by tag using the same form
+described above. So for example if the patch contains::
+
+	<changelog>
+
+	Sponsored-by: Company Name <mail@companyname.com>
+	Signed-off-by: Developer Name <developer.name@developername.com>
+
+The result including the answer from the sponsor must be::
+
+	<changelog>
+
+	Sponsored-by: Company Name <mail@companyname.com>
+	Acked-by: Company Name <mail@companyname.com>
+	Signed-off-by: Developer Name <developer.name@developername.com>
+
+This way the sponsor agrees to the usage of this tag using its name.
+
 .. _the_canonical_patch_format:
 
 The canonical patch format
-- 
2.34.1

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Laurent Pinchart]

Hi Giulio,

On Fri, Aug 18, 2023 at 12:09:57AM +0200, Giulio Benetti wrote:
> Sometimes it happens that a Company or a Physical Person sponsors the
> creation and/or the upstreaming process of a patch, but at the moment
> there is no way to give credits to it. There are some commit that include
> a sort of tag "Sponsored by" without the dash to avoid
> scripts/checkpatch.pl to complain but a real standard has not been defined.
> With this patch let's try to define a method to give credits consistently
> including an acknowledge from the sponsor. The goal is to improve
> contributions from companies or physical persons that this way should gain
> visibility in Linux kernel and so they should be more prone to let the
> work done for them for to be upstreamed.

Just adding one data point here, without judging on the merits of this
proposal. I've been requested previously by customers to increase their
visibility in the kernel development statistics, and the way we found to
do so was to sign-off patches with

Laurent Pinchart <laurent.pinchart+customer@ideasonboard.com>

(where "customer" is to be replaced with the customer name).

> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
> ---
>  Documentation/process/submitting-patches.rst | 38 ++++++++++++++++++++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index efac910e2659..870e6b5def3f 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -600,6 +600,44 @@ process nor the requirement to Cc: stable@vger.kernel.org on all stable
>  patch candidates. For more information, please read
>  Documentation/process/stable-kernel-rules.rst.
>  
> +Using Sponsored-by:
> +-------------------
> +
> +A Sponsored-by tag gives credit to who sponsored the creation and/or the
> +upstreaming process of the patch. Sponsored-by can contain a company name or
> +a physical person name. If a company sponsored the patch this is the form::
> +
> +	Company Name <mail@companyname.com>
> +
> +where the Company Name must be a valid Business Name at the time of sending the
> +patch until the confirmation of the Sponsored-by tag, while the e-mail can be
> +either a generic e-mail the company can be reached out or an e-mail of a person
> +who has the rights inside it to confirm the Sponsored-by tag.
> +
> +If a physical person sponsored the patch the form must be same used in
> +Signed-off-by tag::
> +
> +	Physical Person <physical.person@mail.com>
> +
> +In both cases, to prevent fake credits, either the company or the person should
> +send an Acked-by tag placed right under Sponsored-by tag using the same form
> +described above. So for example if the patch contains::
> +
> +	<changelog>
> +
> +	Sponsored-by: Company Name <mail@companyname.com>
> +	Signed-off-by: Developer Name <developer.name@developername.com>
> +
> +The result including the answer from the sponsor must be::
> +
> +	<changelog>
> +
> +	Sponsored-by: Company Name <mail@companyname.com>
> +	Acked-by: Company Name <mail@companyname.com>
> +	Signed-off-by: Developer Name <developer.name@developername.com>
> +
> +This way the sponsor agrees to the usage of this tag using its name.
> +
>  .. _the_canonical_patch_format:
>  
>  The canonical patch format

-- 
Regards,

Laurent Pinchart

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Matthew Wilcox]

On Fri, Aug 18, 2023 at 02:23:48AM +0300, Laurent Pinchart wrote:
> Just adding one data point here, without judging on the merits of this
> proposal. I've been requested previously by customers to increase their
> visibility in the kernel development statistics, and the way we found to
> do so was to sign-off patches with
> 
> Laurent Pinchart <laurent.pinchart+customer@ideasonboard.com>
> 
> (where "customer" is to be replaced with the customer name).

I quite like Sponsored-by: but yet another approach could be the
same as that used by those of us whole use personal email addresses
while being employed by someone.  So my SoB is:

Matthew Wilcox (Oracle) <willy@infradead.org>

but you might have (eg)

Laurent Pinchard (Coca-Cola) <laurent.pinchart@ideasonboard.com>

and then when working for another sponsor:

Laurent Pinchard (Ford) <laurent.pinchart@ideasonboard.com>

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Giulio Benetti]

Hi Laurent,

On 18/08/23 01:23, Laurent Pinchart wrote:
> Hi Giulio,
> 
> On Fri, Aug 18, 2023 at 12:09:57AM +0200, Giulio Benetti wrote:
>> Sometimes it happens that a Company or a Physical Person sponsors the
>> creation and/or the upstreaming process of a patch, but at the moment
>> there is no way to give credits to it. There are some commit that include
>> a sort of tag "Sponsored by" without the dash to avoid
>> scripts/checkpatch.pl to complain but a real standard has not been defined.
>> With this patch let's try to define a method to give credits consistently
>> including an acknowledge from the sponsor. The goal is to improve
>> contributions from companies or physical persons that this way should gain
>> visibility in Linux kernel and so they should be more prone to let the
>> work done for them for to be upstreamed.
> 
> Just adding one data point here, without judging on the merits of this
> proposal. I've been requested previously by customers to increase their
> visibility in the kernel development statistics, and the way we found to
> do so was to sign-off patches with
> 
> Laurent Pinchart <laurent.pinchart+customer@ideasonboard.com>
> 
> (where "customer" is to be replaced with the customer name).

this approach works good for the developer because of the +customer
mailbox capability but in term of appeal for the final customer I've
been told(by the customer) he would really like more the "Sponsored-by:"
way. To tell the truth while I was looking for an existing alternative
I've found the commits with "Sponsored by:" pseudo-tag that look cooler.

This is my taste of course and the taste of one of my customers, but
to me it's like having a brand shown:
Sponsored-by: Sponsoring Company
vs:
Signed-off-by: Giulio Benetti 
<giulio.benetti+sponsor.company@benettiengineering.com>

If I am the customer I'd really prefer the first option.

Kind regards
-- 
Giulio Benetti
CEO&CTO@Benetti Engineering sas

>> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
>> ---
>>   Documentation/process/submitting-patches.rst | 38 ++++++++++++++++++++
>>   1 file changed, 38 insertions(+)
>>
>> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
>> index efac910e2659..870e6b5def3f 100644
>> --- a/Documentation/process/submitting-patches.rst
>> +++ b/Documentation/process/submitting-patches.rst
>> @@ -600,6 +600,44 @@ process nor the requirement to Cc: stable@vger.kernel.org on all stable
>>   patch candidates. For more information, please read
>>   Documentation/process/stable-kernel-rules.rst.
>>   
>> +Using Sponsored-by:
>> +-------------------
>> +
>> +A Sponsored-by tag gives credit to who sponsored the creation and/or the
>> +upstreaming process of the patch. Sponsored-by can contain a company name or
>> +a physical person name. If a company sponsored the patch this is the form::
>> +
>> +	Company Name <mail@companyname.com>
>> +
>> +where the Company Name must be a valid Business Name at the time of sending the
>> +patch until the confirmation of the Sponsored-by tag, while the e-mail can be
>> +either a generic e-mail the company can be reached out or an e-mail of a person
>> +who has the rights inside it to confirm the Sponsored-by tag.
>> +
>> +If a physical person sponsored the patch the form must be same used in
>> +Signed-off-by tag::
>> +
>> +	Physical Person <physical.person@mail.com>
>> +
>> +In both cases, to prevent fake credits, either the company or the person should
>> +send an Acked-by tag placed right under Sponsored-by tag using the same form
>> +described above. So for example if the patch contains::
>> +
>> +	<changelog>
>> +
>> +	Sponsored-by: Company Name <mail@companyname.com>
>> +	Signed-off-by: Developer Name <developer.name@developername.com>
>> +
>> +The result including the answer from the sponsor must be::
>> +
>> +	<changelog>
>> +
>> +	Sponsored-by: Company Name <mail@companyname.com>
>> +	Acked-by: Company Name <mail@companyname.com>
>> +	Signed-off-by: Developer Name <developer.name@developername.com>
>> +
>> +This way the sponsor agrees to the usage of this tag using its name.
>> +
>>   .. _the_canonical_patch_format:
>>   
>>   The canonical patch format
> 

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Giulio Benetti]

Hello Matthew, Laurent,

On 18/08/23 02:21, Matthew Wilcox wrote:
> On Fri, Aug 18, 2023 at 02:23:48AM +0300, Laurent Pinchart wrote:
>> Just adding one data point here, without judging on the merits of this
>> proposal. I've been requested previously by customers to increase their
>> visibility in the kernel development statistics, and the way we found to
>> do so was to sign-off patches with
>>
>> Laurent Pinchart <laurent.pinchart+customer@ideasonboard.com>
>>
>> (where "customer" is to be replaced with the customer name).
> 
> I quite like Sponsored-by: but yet another approach could be the
> same as that used by those of us whole use personal email addresses
> while being employed by someone.  So my SoB is:
> 
> Matthew Wilcox (Oracle) <willy@infradead.org>
> 
> but you might have (eg)
> 
> Laurent Pinchard (Coca-Cola) <laurent.pinchart@ideasonboard.com>
> 
> and then when working for another sponsor:
> 
> Laurent Pinchard (Ford) <laurent.pinchart@ideasonboard.com>

This is a good solution too. It's only that it gives me the idea that
Laurent Pinchard actually works inside Coca-Cola then Ford and so on.
At the least this is my understanding at first sight.

What I've found not easy at all instead in my patch is to deal with the
Acked-by: from the Sponsor, because he could have to do that for(let's
say) 100 patches, and it becomes not easy to check.
I've been pointed that there is already the DCO the prevents from fake
Sponsored-by: tags removing the need to send Acked-by: from the Sponsor.
So I would modify this patch.

But before I'd really like to have more feedback by someone else if 
possible.

-- 
Giulio Benetti
CEO&CTO@Benetti Engineering sas

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Geert Uytterhoeven]

Hi Giulio,

On Sun, Aug 20, 2023 at 2:35 AM Giulio Benetti
<giulio.benetti@benettiengineering.com> wrote:
> On 18/08/23 01:23, Laurent Pinchart wrote:
> > On Fri, Aug 18, 2023 at 12:09:57AM +0200, Giulio Benetti wrote:
> >> Sometimes it happens that a Company or a Physical Person sponsors the
> >> creation and/or the upstreaming process of a patch, but at the moment
> >> there is no way to give credits to it. There are some commit that include
> >> a sort of tag "Sponsored by" without the dash to avoid
> >> scripts/checkpatch.pl to complain but a real standard has not been defined.
> >> With this patch let's try to define a method to give credits consistently
> >> including an acknowledge from the sponsor. The goal is to improve
> >> contributions from companies or physical persons that this way should gain
> >> visibility in Linux kernel and so they should be more prone to let the
> >> work done for them for to be upstreamed.
> >
> > Just adding one data point here, without judging on the merits of this
> > proposal. I've been requested previously by customers to increase their
> > visibility in the kernel development statistics, and the way we found to
> > do so was to sign-off patches with
> >
> > Laurent Pinchart <laurent.pinchart+customer@ideasonboard.com>
> >
> > (where "customer" is to be replaced with the customer name).
>
> this approach works good for the developer because of the +customer
> mailbox capability but in term of appeal for the final customer I've
> been told(by the customer) he would really like more the "Sponsored-by:"
> way. To tell the truth while I was looking for an existing alternative
> I've found the commits with "Sponsored by:" pseudo-tag that look cooler.
>
> This is my taste of course and the taste of one of my customers, but
> to me it's like having a brand shown:
> Sponsored-by: Sponsoring Company
> vs:
> Signed-off-by: Giulio Benetti
> <giulio.benetti+sponsor.company@benettiengineering.com>

Personally, I would respond "I'm sorry, but the only advertising
space we offer are Copyright headers (for employees) and
"user+customer@..." or "name (customer) user@..." (for contractors).

And this is a separate tag, so it's harder for the analysis tools
(whose output your customers must be interested in, too?) to
match the tag to the actual Author/Reviewer/...

> If I am the customer I'd really prefer the first option.

You are aware this will cause lots of work for the customer, too?
(See below).

> >> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
> >> ---
> >>   Documentation/process/submitting-patches.rst | 38 ++++++++++++++++++++
> >>   1 file changed, 38 insertions(+)
> >>
> >> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> >> index efac910e2659..870e6b5def3f 100644
> >> --- a/Documentation/process/submitting-patches.rst
> >> +++ b/Documentation/process/submitting-patches.rst
> >> @@ -600,6 +600,44 @@ process nor the requirement to Cc: stable@vger.kernel.org on all stable
> >>   patch candidates. For more information, please read
> >>   Documentation/process/stable-kernel-rules.rst.
> >>
> >> +Using Sponsored-by:
> >> +-------------------
> >> +
> >> +A Sponsored-by tag gives credit to who sponsored the creation and/or the
> >> +upstreaming process of the patch. Sponsored-by can contain a company name or
> >> +a physical person name. If a company sponsored the patch this is the form::
> >> +
> >> +    Company Name <mail@companyname.com>
> >> +
> >> +where the Company Name must be a valid Business Name at the time of sending the
> >> +patch until the confirmation of the Sponsored-by tag, while the e-mail can be
> >> +either a generic e-mail the company can be reached out or an e-mail of a person
> >> +who has the rights inside it to confirm the Sponsored-by tag.
> >> +
> >> +If a physical person sponsored the patch the form must be same used in
> >> +Signed-off-by tag::
> >> +
> >> +    Physical Person <physical.person@mail.com>
> >> +
> >> +In both cases, to prevent fake credits, either the company or the person should
> >> +send an Acked-by tag placed right under Sponsored-by tag using the same form
> >> +described above. So for example if the patch contains::
> >> +
> >> +    <changelog>
> >> +
> >> +    Sponsored-by: Company Name <mail@companyname.com>
> >> +    Signed-off-by: Developer Name <developer.name@developername.com>
> >> +
> >> +The result including the answer from the sponsor must be::
> >> +
> >> +    <changelog>
> >> +
> >> +    Sponsored-by: Company Name <mail@companyname.com>
> >> +    Acked-by: Company Name <mail@companyname.com>
> >> +    Signed-off-by: Developer Name <developer.name@developername.com>
> >> +
> >> +This way the sponsor agrees to the usage of this tag using its name.

This is also causing more work for maintainers: now they have to check
if any Sponsored-by tags are present, and track if there is a response
with a matching Acked-by tag...

And obviously they should postpone applying the patch until a
confirmation response is sent... which may never happen...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Jani Nikula]

On Fri, 18 Aug 2023, Matthew Wilcox <willy@infradead.org> wrote:
> On Fri, Aug 18, 2023 at 02:23:48AM +0300, Laurent Pinchart wrote:
>> Just adding one data point here, without judging on the merits of this
>> proposal. I've been requested previously by customers to increase their
>> visibility in the kernel development statistics, and the way we found to
>> do so was to sign-off patches with
>> 
>> Laurent Pinchart <laurent.pinchart+customer@ideasonboard.com>
>> 
>> (where "customer" is to be replaced with the customer name).
>
> I quite like Sponsored-by: but yet another approach could be the
> same as that used by those of us whole use personal email addresses
> while being employed by someone.  So my SoB is:
>
> Matthew Wilcox (Oracle) <willy@infradead.org>
>
> but you might have (eg)
>
> Laurent Pinchard (Coca-Cola) <laurent.pinchart@ideasonboard.com>
>
> and then when working for another sponsor:
>
> Laurent Pinchard (Ford) <laurent.pinchart@ideasonboard.com>

Just an observation, git shortlog -s/-se groups/distinguishes,
respectively, the author and sponsor in Laurent's approach. Not so with
Matthew's approach.

Probably depends on the POV which approach this favors. ;)


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Toke Høiland-Jørgensen]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> Hi Giulio,
>
> On Sun, Aug 20, 2023 at 2:35 AM Giulio Benetti
> <giulio.benetti@benettiengineering.com> wrote:
>> On 18/08/23 01:23, Laurent Pinchart wrote:
>> > On Fri, Aug 18, 2023 at 12:09:57AM +0200, Giulio Benetti wrote:
>> >> Sometimes it happens that a Company or a Physical Person sponsors the
>> >> creation and/or the upstreaming process of a patch, but at the moment
>> >> there is no way to give credits to it. There are some commit that include
>> >> a sort of tag "Sponsored by" without the dash to avoid
>> >> scripts/checkpatch.pl to complain but a real standard has not been defined.
>> >> With this patch let's try to define a method to give credits consistently
>> >> including an acknowledge from the sponsor. The goal is to improve
>> >> contributions from companies or physical persons that this way should gain
>> >> visibility in Linux kernel and so they should be more prone to let the
>> >> work done for them for to be upstreamed.
>> >
>> > Just adding one data point here, without judging on the merits of this
>> > proposal. I've been requested previously by customers to increase their
>> > visibility in the kernel development statistics, and the way we found to
>> > do so was to sign-off patches with
>> >
>> > Laurent Pinchart <laurent.pinchart+customer@ideasonboard.com>
>> >
>> > (where "customer" is to be replaced with the customer name).
>>
>> this approach works good for the developer because of the +customer
>> mailbox capability but in term of appeal for the final customer I've
>> been told(by the customer) he would really like more the "Sponsored-by:"
>> way. To tell the truth while I was looking for an existing alternative
>> I've found the commits with "Sponsored by:" pseudo-tag that look cooler.
>>
>> This is my taste of course and the taste of one of my customers, but
>> to me it's like having a brand shown:
>> Sponsored-by: Sponsoring Company
>> vs:
>> Signed-off-by: Giulio Benetti
>> <giulio.benetti+sponsor.company@benettiengineering.com>
>
> Personally, I would respond "I'm sorry, but the only advertising
> space we offer are Copyright headers (for employees) and
> "user+customer@..." or "name (customer) user@..." (for contractors).
>
> And this is a separate tag, so it's harder for the analysis tools
> (whose output your customers must be interested in, too?) to
> match the tag to the actual Author/Reviewer/...
>
>> If I am the customer I'd really prefer the first option.
>
> You are aware this will cause lots of work for the customer, too?
> (See below).
>
>> >> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
>> >> ---
>> >>   Documentation/process/submitting-patches.rst | 38 ++++++++++++++++++++
>> >>   1 file changed, 38 insertions(+)
>> >>
>> >> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
>> >> index efac910e2659..870e6b5def3f 100644
>> >> --- a/Documentation/process/submitting-patches.rst
>> >> +++ b/Documentation/process/submitting-patches.rst
>> >> @@ -600,6 +600,44 @@ process nor the requirement to Cc: stable@vger.kernel.org on all stable
>> >>   patch candidates. For more information, please read
>> >>   Documentation/process/stable-kernel-rules.rst.
>> >>
>> >> +Using Sponsored-by:
>> >> +-------------------
>> >> +
>> >> +A Sponsored-by tag gives credit to who sponsored the creation and/or the
>> >> +upstreaming process of the patch. Sponsored-by can contain a company name or
>> >> +a physical person name. If a company sponsored the patch this is the form::
>> >> +
>> >> +    Company Name <mail@companyname.com>
>> >> +
>> >> +where the Company Name must be a valid Business Name at the time of sending the
>> >> +patch until the confirmation of the Sponsored-by tag, while the e-mail can be
>> >> +either a generic e-mail the company can be reached out or an e-mail of a person
>> >> +who has the rights inside it to confirm the Sponsored-by tag.
>> >> +
>> >> +If a physical person sponsored the patch the form must be same used in
>> >> +Signed-off-by tag::
>> >> +
>> >> +    Physical Person <physical.person@mail.com>
>> >> +
>> >> +In both cases, to prevent fake credits, either the company or the person should
>> >> +send an Acked-by tag placed right under Sponsored-by tag using the same form
>> >> +described above. So for example if the patch contains::
>> >> +
>> >> +    <changelog>
>> >> +
>> >> +    Sponsored-by: Company Name <mail@companyname.com>
>> >> +    Signed-off-by: Developer Name <developer.name@developername.com>
>> >> +
>> >> +The result including the answer from the sponsor must be::
>> >> +
>> >> +    <changelog>
>> >> +
>> >> +    Sponsored-by: Company Name <mail@companyname.com>
>> >> +    Acked-by: Company Name <mail@companyname.com>
>> >> +    Signed-off-by: Developer Name <developer.name@developername.com>
>> >> +
>> >> +This way the sponsor agrees to the usage of this tag using its name.
>
> This is also causing more work for maintainers: now they have to check
> if any Sponsored-by tags are present, and track if there is a response
> with a matching Acked-by tag...
>
> And obviously they should postpone applying the patch until a
> confirmation response is sent... which may never happen...

Yeah, definitely not going to track that. I'm pretty agnostic to the tag
itself, but please don't put the burden of validity testing of it on
maintainers...

-Toke

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Matthew Wilcox]

On Mon, Aug 21, 2023 at 11:29:27AM +0300, Jani Nikula wrote:
> On Fri, 18 Aug 2023, Matthew Wilcox <willy@infradead.org> wrote:
> > but you might have (eg)
> >
> > Laurent Pinchard (Coca-Cola) <laurent.pinchart@ideasonboard.com>
> >
> > and then when working for another sponsor:
> >
> > Laurent Pinchard (Ford) <laurent.pinchart@ideasonboard.com>
> 
> Just an observation, git shortlog -s/-se groups/distinguishes,
> respectively, the author and sponsor in Laurent's approach. Not so with
> Matthew's approach.

Hm?

$ git shortlog -s next-20230817..
     1  Matthew Wilcox (Novartis)
    25  Matthew Wilcox (Oracle)

$ git shortlog -se next-20230817..
     1  Matthew Wilcox (Novartis) <willy@infradead.org>
    25  Matthew Wilcox (Oracle) <willy@infradead.org>

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Jani Nikula]

On Mon, 21 Aug 2023, Matthew Wilcox <willy@infradead.org> wrote:
> On Mon, Aug 21, 2023 at 11:29:27AM +0300, Jani Nikula wrote:
>> On Fri, 18 Aug 2023, Matthew Wilcox <willy@infradead.org> wrote:
>> > but you might have (eg)
>> >
>> > Laurent Pinchard (Coca-Cola) <laurent.pinchart@ideasonboard.com>
>> >
>> > and then when working for another sponsor:
>> >
>> > Laurent Pinchard (Ford) <laurent.pinchart@ideasonboard.com>
>> 
>> Just an observation, git shortlog -s/-se groups/distinguishes,
>> respectively, the author and sponsor in Laurent's approach. Not so with
>> Matthew's approach.
>
> Hm?
>
> $ git shortlog -s next-20230817..
>      1  Matthew Wilcox (Novartis)
>     25  Matthew Wilcox (Oracle)
>
> $ git shortlog -se next-20230817..
>      1  Matthew Wilcox (Novartis) <willy@infradead.org>
>     25  Matthew Wilcox (Oracle) <willy@infradead.org>

$ git shortlog v6.4.. -s --author="Laurent Pinchart"
    12  Laurent Pinchart

$ git shortlog v6.4.. -se --author="Laurent Pinchart"
     2  Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    10  Laurent Pinchart <laurent.pinchart@ideasonboard.com>

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Matthew Wilcox]

On Mon, Aug 21, 2023 at 03:15:43PM +0300, Jani Nikula wrote:
> On Mon, 21 Aug 2023, Matthew Wilcox <willy@infradead.org> wrote:
> > On Mon, Aug 21, 2023 at 11:29:27AM +0300, Jani Nikula wrote:
> >> On Fri, 18 Aug 2023, Matthew Wilcox <willy@infradead.org> wrote:
> >> > but you might have (eg)
> >> >
> >> > Laurent Pinchard (Coca-Cola) <laurent.pinchart@ideasonboard.com>
> >> >
> >> > and then when working for another sponsor:
> >> >
> >> > Laurent Pinchard (Ford) <laurent.pinchart@ideasonboard.com>
> >> 
> >> Just an observation, git shortlog -s/-se groups/distinguishes,
> >> respectively, the author and sponsor in Laurent's approach. Not so with
> >> Matthew's approach.
> >
> > Hm?
> >
> > $ git shortlog -s next-20230817..
> >      1  Matthew Wilcox (Novartis)
> >     25  Matthew Wilcox (Oracle)
> >
> > $ git shortlog -se next-20230817..
> >      1  Matthew Wilcox (Novartis) <willy@infradead.org>
> >     25  Matthew Wilcox (Oracle) <willy@infradead.org>
> 
> $ git shortlog v6.4.. -s --author="Laurent Pinchart"
>     12  Laurent Pinchart
> 
> $ git shortlog v6.4.. -se --author="Laurent Pinchart"
>      2  Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>     10  Laurent Pinchart <laurent.pinchart@ideasonboard.com>

I must not be understanding your point correctly.

$ git shortlog v6.4.. -s --author="Matthew Wilcox"
     7  Matthew Wilcox
     1  Matthew Wilcox (Novartis)
   123  Matthew Wilcox (Oracle)

That seems to me like it successfully distinguishes my fake commit on
behalf of Novartis (who I haven't actually worked for since 1997) from
my real commits on behalf of Oracle.  It also shows a few places where
my commits weren't attributed to Oracle (I think this happens when I
send patches using mutt instead of git-send-email)

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Jani Nikula]

On Mon, 21 Aug 2023, Matthew Wilcox <willy@infradead.org> wrote:
> On Mon, Aug 21, 2023 at 03:15:43PM +0300, Jani Nikula wrote:
>> On Mon, 21 Aug 2023, Matthew Wilcox <willy@infradead.org> wrote:
>> > On Mon, Aug 21, 2023 at 11:29:27AM +0300, Jani Nikula wrote:
>> >> On Fri, 18 Aug 2023, Matthew Wilcox <willy@infradead.org> wrote:
>> >> > but you might have (eg)
>> >> >
>> >> > Laurent Pinchard (Coca-Cola) <laurent.pinchart@ideasonboard.com>
>> >> >
>> >> > and then when working for another sponsor:
>> >> >
>> >> > Laurent Pinchard (Ford) <laurent.pinchart@ideasonboard.com>
>> >> 
>> >> Just an observation, git shortlog -s/-se groups/distinguishes,
>> >> respectively, the author and sponsor in Laurent's approach. Not so with
>> >> Matthew's approach.
>> >
>> > Hm?
>> >
>> > $ git shortlog -s next-20230817..
>> >      1  Matthew Wilcox (Novartis)
>> >     25  Matthew Wilcox (Oracle)
>> >
>> > $ git shortlog -se next-20230817..
>> >      1  Matthew Wilcox (Novartis) <willy@infradead.org>
>> >     25  Matthew Wilcox (Oracle) <willy@infradead.org>
>> 
>> $ git shortlog v6.4.. -s --author="Laurent Pinchart"
>>     12  Laurent Pinchart
>> 
>> $ git shortlog v6.4.. -se --author="Laurent Pinchart"
>>      2  Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>>     10  Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> I must not be understanding your point correctly.

That's probably a correct assesment, and not necessarily your fault. ;)

My point was that git shortlog -s groups and adds up the commits
together if the name is the same, but -se can still be used to
distinguish the mbox+tag difference in email. 12 for -s, but 2 and 10
for -se in Laurent's stats above.

If the names differ, even if just by the thing in parens, git shortlog
won't combine them.

> $ git shortlog v6.4.. -s --author="Matthew Wilcox"
>      7  Matthew Wilcox
>      1  Matthew Wilcox (Novartis)
>    123  Matthew Wilcox (Oracle)
>
> That seems to me like it successfully distinguishes my fake commit on
> behalf of Novartis (who I haven't actually worked for since 1997) from
> my real commits on behalf of Oracle.  It also shows a few places where
> my commits weren't attributed to Oracle (I think this happens when I
> send patches using mutt instead of git-send-email)

I'm not saying either is right or wrong or has any shortcomings, I'm
just saying they're *different* in this regard.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Jakub Kicinski]

On Mon, 21 Aug 2023 09:40:59 +0200 Geert Uytterhoeven wrote:
> Personally, I would respond "I'm sorry, but the only advertising
> space we offer are Copyright headers (for employees) and
> "user+customer@..." or "name (customer) user@..." (for contractors).

+1

> And this is a separate tag, so it's harder for the analysis tools
> (whose output your customers must be interested in, too?) to
> match the tag to the actual Author/Reviewer/...

I think that's a key point. Having a separate tag denote the sponsor
would make analysis a lot harder. We'd need to start writing parsers
with much more context awareness.

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Giulio Benetti]

Hello Geert, All,

On 21/08/23 09:40, Geert Uytterhoeven wrote:
> Hi Giulio,
> 
> On Sun, Aug 20, 2023 at 2:35 AM Giulio Benetti
> <giulio.benetti@benettiengineering.com> wrote:
>> On 18/08/23 01:23, Laurent Pinchart wrote:
>>> On Fri, Aug 18, 2023 at 12:09:57AM +0200, Giulio Benetti wrote:
>>>> Sometimes it happens that a Company or a Physical Person sponsors the
>>>> creation and/or the upstreaming process of a patch, but at the moment
>>>> there is no way to give credits to it. There are some commit that include
>>>> a sort of tag "Sponsored by" without the dash to avoid
>>>> scripts/checkpatch.pl to complain but a real standard has not been defined.
>>>> With this patch let's try to define a method to give credits consistently
>>>> including an acknowledge from the sponsor. The goal is to improve
>>>> contributions from companies or physical persons that this way should gain
>>>> visibility in Linux kernel and so they should be more prone to let the
>>>> work done for them for to be upstreamed.
>>>
>>> Just adding one data point here, without judging on the merits of this
>>> proposal. I've been requested previously by customers to increase their
>>> visibility in the kernel development statistics, and the way we found to
>>> do so was to sign-off patches with
>>>
>>> Laurent Pinchart <laurent.pinchart+customer@ideasonboard.com>
>>>
>>> (where "customer" is to be replaced with the customer name).
>>
>> this approach works good for the developer because of the +customer
>> mailbox capability but in term of appeal for the final customer I've
>> been told(by the customer) he would really like more the "Sponsored-by:"
>> way. To tell the truth while I was looking for an existing alternative
>> I've found the commits with "Sponsored by:" pseudo-tag that look cooler.
>>
>> This is my taste of course and the taste of one of my customers, but
>> to me it's like having a brand shown:
>> Sponsored-by: Sponsoring Company
>> vs:
>> Signed-off-by: Giulio Benetti
>> <giulio.benetti+sponsor.company@benettiengineering.com>
> 
> Personally, I would respond "I'm sorry, but the only advertising
> space we offer are Copyright headers (for employees) and
> "user+customer@..." or "name (customer) user@..." (for contractors).

This is a good answer. So these are the 2 possible ways to give credits
to sponsors.

Does it make sense if I send a patch describing exactly this?
This is because my finding was only "Sponsored by" that looked good
to me. So I can avoid other possible pain for the future.

> And this is a separate tag, so it's harder for the analysis tools
> (whose output your customers must be interested in, too?) to
> match the tag to the actual Author/Reviewer/...

Right

>> If I am the customer I'd really prefer the first option.
> 
> You are aware this will cause lots of work for the customer, too?
> (See below).

[ SNIP ]

>>>> +In both cases, to prevent fake credits, either the company or the person should
>>>> +send an Acked-by tag placed right under Sponsored-by tag using the same form
>>>> +described above. So for example if the patch contains::
>>>> +
>>>> +    <changelog>
>>>> +
>>>> +    Sponsored-by: Company Name <mail@companyname.com>
>>>> +    Signed-off-by: Developer Name <developer.name@developername.com>
>>>> +
>>>> +The result including the answer from the sponsor must be::
>>>> +
>>>> +    <changelog>
>>>> +
>>>> +    Sponsored-by: Company Name <mail@companyname.com>
>>>> +    Acked-by: Company Name <mail@companyname.com>
>>>> +    Signed-off-by: Developer Name <developer.name@developername.com>
>>>> +
>>>> +This way the sponsor agrees to the usage of this tag using its name.
> 
> This is also causing more work for maintainers: now they have to check
> if any Sponsored-by tags are present, and track if there is a response
> with a matching Acked-by tag...
> 
> And obviously they should postpone applying the patch until a
> confirmation response is sent... which may never happen...

Yes it came into my mind and I wanted to rely only on DCO dropping the
part of acked-by tag. But there are too many cons for Sponsored-by approach.

So I will go for one of the 2 ways I've been pointed.

Thank you
Best regards
-- 
Giulio Benetti
CEO&CTO@Benetti Engineering sas

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Giulio Benetti]

Hello Toke, All,

On 21/08/23 11:27, Toke Høiland-Jørgensen wrote:

[ SNIP ]

>>
>> This is also causing more work for maintainers: now they have to check
>> if any Sponsored-by tags are present, and track if there is a response
>> with a matching Acked-by tag...
>>
>> And obviously they should postpone applying the patch until a
>> confirmation response is sent... which may never happen...
> 
> Yeah, definitely not going to track that. I'm pretty agnostic to the tag
> itself, but please don't put the burden of validity testing of it on
> maintainers...

yes, I've realized only later what could this imply for Maintainers and
for Customers too in the end.

Thank you for replying!
Best regards
-- 
Giulio Benetti
CEO&CTO@Benetti Engineering sas

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Giulio Benetti]

Hello Jacub, All,

On 21/08/23 16:57, Jakub Kicinski wrote:
> On Mon, 21 Aug 2023 09:40:59 +0200 Geert Uytterhoeven wrote:
>> Personally, I would respond "I'm sorry, but the only advertising
>> space we offer are Copyright headers (for employees) and
>> "user+customer@..." or "name (customer) user@..." (for contractors).
> 
> +1
> 
>> And this is a separate tag, so it's harder for the analysis tools
>> (whose output your customers must be interested in, too?) to
>> match the tag to the actual Author/Reviewer/...
> 
> I think that's a key point. Having a separate tag denote the sponsor
> would make analysis a lot harder. We'd need to start writing parsers
> with much more context awareness.

yes. There are already 2 ways to give credits I was not aware and I
will go with one of those.

Thank you for replying
Best regards
-- 
Giulio Benetti
CEO&CTO@Benetti Engineering sas

Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch

[Giulio Benetti]

Hello Matthew, Laurent, All,

On 18/08/23 02:21, Matthew Wilcox wrote:
> On Fri, Aug 18, 2023 at 02:23:48AM +0300, Laurent Pinchart wrote:
>> Just adding one data point here, without judging on the merits of this
>> proposal. I've been requested previously by customers to increase their
>> visibility in the kernel development statistics, and the way we found to
>> do so was to sign-off patches with
>>
>> Laurent Pinchart <laurent.pinchart+customer@ideasonboard.com>
>>
>> (where "customer" is to be replaced with the customer name).
> 
> I quite like Sponsored-by: but yet another approach could be the
> same as that used by those of us whole use personal email addresses
> while being employed by someone.  So my SoB is:
> 
> Matthew Wilcox (Oracle) <willy@infradead.org>
> 
> but you might have (eg)
> 
> Laurent Pinchard (Coca-Cola) <laurent.pinchart@ideasonboard.com>
> 
> and then when working for another sponsor:
> 
> Laurent Pinchard (Ford) <laurent.pinchart@ideasonboard.com>
> 

Thanks a lot for pointing me the existing ways to give credits I was not
aware. I will pick one of the 2 and use it.

Both can be used by analysis tools.

Thanks again for taking care.
Best regards
-- 
Giulio Benetti
CEO&CTO@Benetti Engineering sas