lkml.org 
[lkml]   [2023]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to give credits to who sponsored the patch
From
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

\
 
 \ /
  Last update: 2023-08-24 01:20    [W:0.118 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site