lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <28289906-4fd1-26aa-b1c4-eb393ac52d48@benettiengineering.com>
Date:   Sat, 19 Aug 2023 22:39:13 +0200
From:   Giulio Benetti <giulio.benetti@...ettiengineering.com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Jonathan Corbet <corbet@....net>, workflows@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/1] docs: submitting-patches: Add Sponsored-by tag to
 give credits to who sponsored the patch

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@...asonboard.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@...ettiengineering.com>

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

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

>> Signed-off-by: Giulio Benetti <giulio.benetti@...ettiengineering.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@...r.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@...panyname.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@...l.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@...panyname.com>
>> +	Signed-off-by: Developer Name <developer.name@...elopername.com>
>> +
>> +The result including the answer from the sponsor must be::
>> +
>> +	<changelog>
>> +
>> +	Sponsored-by: Company Name <mail@...panyname.com>
>> +	Acked-by: Company Name <mail@...panyname.com>
>> +	Signed-off-by: Developer Name <developer.name@...elopername.com>
>> +
>> +This way the sponsor agrees to the usage of this tag using its name.
>> +
>>   .. _the_canonical_patch_format:
>>   
>>   The canonical patch format
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ