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: <CALAqxLUXnPRec3UYbMKge8yNKBagLOatOeRCagF=JEyPEfWeKA@mail.gmail.com>
Date:   Wed, 19 Aug 2020 12:52:06 -0700
From:   John Stultz <john.stultz@...aro.org>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Sam Ravnborg <sam@...nborg.org>,
        Neil Armstrong <narmstrong@...libre.com>,
        David Airlie <airlied@...ux.ie>,
        Wanchun Zheng <zhengwanchun@...ilicon.com>,
        linuxarm@...wei.com, dri-devel <dri-devel@...ts.freedesktop.org>,
        Andrzej Hajda <a.hajda@...sung.com>,
        driverdevel <devel@...verdev.osuosl.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        John Fastabend <john.fastabend@...il.com>,
        Xiubin Zhang <zhangxiubin1@...wei.com>,
        Wei Xu <xuwei5@...ilicon.com>,
        Xinliang Liu <xinliang.liu@...aro.org>,
        Xinwei Kong <kong.kongxinwei@...ilicon.com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Bogdan Togorean <bogdan.togorean@...log.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Laurentiu Palcu <laurentiu.palcu@....com>,
        linux-media <linux-media@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, Liwei Cai <cailiwei@...ilicon.com>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Chen Feng <puck.chen@...ilicon.com>,
        Alexei Starovoitov <ast@...nel.org>,
        "moderated list:DMA BUFFER SHARING FRAMEWORK" 
        <linaro-mm-sig@...ts.linaro.org>, Rob Herring <robh+dt@...nel.org>,
        mauro.chehab@...wei.com, Rob Clark <robdclark@...omium.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Liuyao An <anliuyao@...wei.com>,
        Network Development <netdev@...r.kernel.org>,
        Rongrong Zou <zourongrong@...il.com>,
        BPF Mailing List <bpf@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 00/49] DRM driver for Hikey 970

On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart
<laurent.pinchart@...asonboard.com> wrote:
> On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote:
> > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote:
> > > This patch series port the out-of-tree driver for Hikey 970 (which
> > > should also support Hikey 960) from the official 96boards tree:
> > >
> > >    https://github.com/96boards-hikey/linux/tree/hikey970-v4.9
> > >
> > > Based on his history, this driver seems to be originally written
> > > for Kernel 4.4, and was later ported to Kernel 4.9. The original
> > > driver used to depend on ION (from Kernel 4.4) and had its own
> > > implementation for FB dev API.
> > >
> > > As I need to preserve the original history (with has patches from
> > > both HiSilicon and from Linaro),  I'm starting from the original
> > > patch applied there. The remaining patches are incremental,
> > > and port this driver to work with upstream Kernel.
> > >
...
> > > - Due to legal reasons, I need to preserve the authorship of
> > >   each one responsbile for each patch. So, I need to start from
> > >   the original patch from Kernel 4.4;
...
> > I do acknowledge you need to preserve history and all -
> > but this patchset is not easy to review.
>
> Why do we need to preserve history ? Adding relevant Signed-off-by and
> Co-developed-by should be enough, shouldn't it ? Having a public branch
> that contains the history is useful if anyone is interested, but I don't
> think it's required in mainline.

Yea. I concur with Laurent here. I'm not sure what legal reasoning you
have on this but preserving the "absolute" history here is actively
detrimental for review and understanding of the patch set.

Preserving Authorship, Signed-off-by lines and adding Co-developed-by
lines should be sufficient to provide both atribution credit and DCO
history.

thanks
-john

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ