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: <2b4f177b-3b8a-fef6-e7a5-692db347679e@amd.com>
Date:   Mon, 6 Mar 2023 09:34:29 -0600
From:   Carlos Bilbao <carlos.bilbao@....com>
To:     Akira Yokosawa <akiyks@...il.com>
Cc:     corbet@....net, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, sergio.collado@...il.com
Subject: Re: [PATCH] docs/sp_SP: Add process deprecated translation

On 3/6/23 09:30, Akira Yokosawa wrote:
> On 2023/03/07 0:20, Carlos Bilbao wrote:
>> Hello Akira,
>>
>> On 3/6/23 09:13, Akira Yokosawa wrote:
>>> Hi Carlos,
>>>
>>> Minor nits in the Subject and Sob area.
>>>
>>> On Mon, 6 Mar 2023 07:44:20 -0600, Carlos Bilbao wrote:
>>>> Subject: [PATCH] docs/sp_SP: Add process deprecated translation
>>>
>>> This summary looks ambiguous to me.
>>>
>>> Maybe
>>>
>>>      docs/sp_SP: Add translation of process/deprecated
>>
>> This summary follows the same format followed in the past. Some examples:
>>
>> docs/sp_SP: Add process coding-style translation
>> docs/sp_SP: Add process magic-number translation
>> docs/sp_SP: Add process programming-language translation
>> docs/sp_SP: Add process email-clients translation
> 
> Let me explain why "Add process deprecated translation" looks
> ambiguous.
> 
> "deprecated translation" can be interpreted as "some translation
> which is deprecated".
> Of course you don't need to agree.

I see what you mean. I'm sending v2 patch renamed to avoid confusion.

> 
>>
>>>
>>> ??
>>>
>>>> Translate Documentation/process/deprecated.rst into Spanish.
>>>>
>>>> Co-developed-by: Carlos Bilbao <carlos.bilbao@....com>
>>>> Signed-off-by: Sergio Gonzalez <sergio.collado@...il.com>
>>>> Signed-off-by: Carlos Bilbao <carlos.bilbao@....com>
>>>
>>> To me, Co-developed-by: from the author of the patch looks
>>> strange, because it is obvious the author did some development on
>>> the patch.
>>>
>>
>> No, we both worked on this patch so Co-developed-by: is the appropriate
>> tagging. That being said, Sergio translated more than I did, so I put
>> him as sole Translator in the document itself.
> 
> Hmm, anyway I don't think you are following the rule of Co-developed-by:
> explained in submitting-patches.rst.
> 
> Again, you don't need to agree... ;-)

But, why doesn't it follow the rule?

The rule is "A Co-Developed-by: states that the patch was also created by 
another developer along with the original author. This is useful at times 
when multiple people work on a single patch."

IMHO this is the case here, but before I send v2 I'll wait to read you 
again in case we agree at that point.

> 
>          Thanks, Akira
> 
>>
>>> Which is your intent:
>>>
>>>      Author: Carlos
>>>      Co-developer: Sergio
>>>
>>> , or
>>>
>>>      Author: Sergio
>>>      Co-developer: Carlos
>>>
>>> ???
>>>
>>>           Thanks, Akira
>>>
>>>> ---
>>>>    .../translations/sp_SP/process/deprecated.rst | 381 ++++++++++++++++++
>>>>    .../translations/sp_SP/process/index.rst      |   1 +
>>>>    2 files changed, 382 insertions(+)
>>>>    create mode 100644 Documentation/translations/sp_SP/process/deprecated.rst
>>> [...]
>>
>> Thanks,
>> Carlos

Thanks,
Carlos

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ