Message-ID: <878ra4bv9s.fsf@toke.dk>
Date:   Mon, 21 Aug 2023 11:27:11 +0200
From:   Toke Høiland-Jørgensen <toke@...nel.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Giulio Benetti <giulio.benetti@...ettiengineering.com>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        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

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

> Hi Giulio,
>
> On Sun, Aug 20, 2023 at 2:35 AM Giulio Benetti
> <giulio.benetti@...ettiengineering.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@...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>
>
> 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@...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.
>
> 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

Powered by blists - more mailing lists