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: <dbd8ece3-fb92-9ca3-917b-4951af7e1593@gmail.com>
Date:   Tue, 7 Mar 2023 08:03:28 +0900
From:   Akira Yokosawa <akiyks@...il.com>
To:     Carlos Bilbao <carlos.bilbao@....com>
Cc:     corbet@....net, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, sergio.collado@...il.com,
        Akira Yokosawa <akiyks@...il.com>
Subject: Re: [PATCH] docs/sp_SP: Add process deprecated translation

On Mon, 6 Mar 2023 09:34:29 -0600, Carlos Bilbao wrote:
> 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.

If you put "From: Sergio" as the first line in the Changelog, like
this submission [1], then the Sob chain would make sense.

[1]: https://lore.kernel.org/linux-doc/20230227222957.24501-2-rick.p.edgecombe@intel.com/

Didn't you forgot to put it there?

Just guessing...

        Thanks, Akira

> 
>>
>>          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