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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191127112445.GA21836@vmlxhi-102.adit-jv.com>
Date:   Wed, 27 Nov 2019 12:25:28 +0100
From:   Eugeniu Rosca <erosca@...adit-jv.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
CC:     Eugeniu Rosca <erosca@...adit-jv.com>,
        Jonathan Corbet <corbet@....net>,
        Joe Perches <joe@...ches.com>,
        Andy Whitcroft <apw@...onical.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Eugeniu Rosca <roscaeugeniu@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] checkpatch: whitelist Originally-by: signature

Hi Geert,

On Wed, Nov 27, 2019 at 10:25:29AM +0100, Geert Uytterhoeven wrote:
[..]
> On Fri, Nov 15, 2019 at 6:24 PM Eugeniu Rosca <erosca@...adit-jv.com> wrote:
[..]
> > I will give a real-life example. Say, I have some patches in my
> > local tree and they've been developed by somebody who is no longer
> > interested/paid to upstream those.
> >
> > I first submit those patches with the original authorship, plus my SoB.
> > Then, the reviewers post their findings. I put my time into fixing those
> > and re-testing the patch or the entire series. The final patch/series
> > may look totally different compared to the original one.
> >
> > Which way would you suggest to give credits to the original author?
> > I personally think that "Co-developed-by:" conveys the idea/feeling of
> > "teaming up" with somebody, which doesn't happen in my example.
> 
> What I typically do is this:
>   1. If the changes due to review are minor, I just add my SoB below the
>      original SoB,
>   2. If the changes are not insignificant, I also add a line "[geert: Did foo]"
>      in between the original SoB and mine,
>   3. If the patch needed a complete rewrite, I assume ownership, and add
>      "Based on/inspired by ..." to the patch description to give credit.
> 
> Hope this helps (and is acceptable for other people ;-)

Thank you for your time to share the best practices from the heart of
Linux kernel community. This looks like a reasonable blueprint to follow
and I will personally bookmark and quote it whenever appropriate.

The way I see "Originally-by" is that it attempts to replace the free
wording implied at #3 (i.e. patch rewrite case) and hence its benefit.

The less words I have to creatively write by myself, the less errors
I'll make, the less ambiguous my patch will be, the more time I'll have
to dedicate to the important parts of the patch description (feature
overview, bug reproduction, test scenario, etc).

I also understand the desire not to make the process more complicated
than it needs to be. I expect the signature to still pop up here and
there and whether it makes sense to whitelist it, time will tell.

-- 
Best Regards,
Eugeniu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ