[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190829065151.GB30423@kroah.com>
Date: Thu, 29 Aug 2019 08:51:51 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Jakub Kicinski <jakub.kicinski@...ronome.com>,
Julia Kartseva <hex@...com>, ast@...nel.org,
Thomas Gleixner <tglx@...utronix.de>, rdna@...com,
bpf@...r.kernel.org, daniel@...earbox.net, netdev@...r.kernel.org,
kernel-team@...com
Subject: Re: auto-split of commit. Was: [PATCH bpf-next 04/10] tools/bpf: add
libbpf_prog_type_(from|to)_str helpers
On Wed, Aug 28, 2019 at 04:46:28PM -0700, Alexei Starovoitov wrote:
> On Wed, Aug 28, 2019 at 04:34:22PM -0700, Jakub Kicinski wrote:
> >
> > Greg, Thomas, libbpf is extracted from the kernel sources and
> > maintained in a clone repo on GitHub for ease of packaging.
> >
> > IIUC Alexei's concern is that since we are moving the commits from
> > the kernel repo to the GitHub one we have to preserve the commits
> > exactly as they are, otherwise SOB lines lose their power.
> >
> > Can you provide some guidance on whether that's a valid concern,
> > or whether it's perfectly fine to apply a partial patch?
>
> Right. That's exactly the concern.
>
> Greg, Thomas,
> could you please put your legal hat on and clarify the following.
> Say some developer does a patch that modifies
> include/uapi/linux/bpf.h
> ..some other kernel code...and
> tools/include/uapi/linux/bpf.h
>
> That tools/include/uapi/linux/bpf.h is used by perf and by libbpf.
> We have automatic mirror of tools/libbpf into github/libbpf/
> so that external projects and can do git submodule of it,
> can build packages out of it, etc.
>
> The question is whether it's ok to split tools/* part out of
> original commit, keep Author and SOB, create new commit out of it,
> and automatically push that auto-generated commit into github mirror.
Note, I am not a laywer, and am not _your_ lawyer either, only _your_
lawyer can answer questions as to what is best for you.
That being said, from a "are you keeping the correct authorship info",
yes, it sounds like you are doing the correct thing here.
Look at what I do for stable kernels, I take the original commit and add
it to "another tree" keeping the original author and s-o-b chain intact,
and adding a "this is the original git commit id" type message to the
changelog text so that people can link it back to the original.
If you are doing that here as well, I don't see how anyone can object.
thanks,
greg k-h
Powered by blists - more mailing lists