netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>,
	Julia Kartseva <hex@fb.com>,
	ast@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	rdna@fb.com, bpf@vger.kernel.org, daniel@iogearbox.net,
	netdev@vger.kernel.org, kernel-team@fb.com
Subject: Re: auto-split of commit. Was: [PATCH bpf-next 04/10] tools/bpf: add libbpf_prog_type_(from|to)_str helpers
Date: Thu, 29 Aug 2019 08:51:51 +0200	[thread overview]
Message-ID: <20190829065151.GB30423@kroah.com> (raw)
In-Reply-To: <20190828234626.ltfy3qr2nne4uumy@ast-mbp.dhcp.thefacebook.com>

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

  reply	other threads:[~2019-08-29  6:51 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-28 21:03 [PATCH bpf-next 00/10] bpf: bpf_(prog|map|attach)_type_(from|to)_str helpers Julia Kartseva
2019-08-28 21:03 ` [PATCH bpf-next 01/10] bpf: introduce __MAX_BPF_PROG_TYPE and __MAX_BPF_MAP_TYPE enum values Julia Kartseva
2019-08-28 21:33   ` Alexei Starovoitov
2019-08-28 21:03 ` [PATCH bpf-next 02/10] tools/bpf: sync bpf.h to tools/ Julia Kartseva
2019-08-28 21:03 ` [PATCH bpf-next 03/10] tools/bpf: handle __MAX_BPF_(PROG|MAP)_TYPE in switch statements Julia Kartseva
2019-08-28 21:19   ` Arnaldo Carvalho de Melo
2019-08-28 21:03 ` [PATCH bpf-next 04/10] tools/bpf: add libbpf_prog_type_(from|to)_str helpers Julia Kartseva
2019-08-28 23:34   ` Jakub Kicinski
2019-08-28 23:46     ` auto-split of commit. Was: " Alexei Starovoitov
2019-08-29  6:51       ` Greg Kroah-Hartman [this message]
2019-08-29 17:16         ` Alexei Starovoitov
2019-08-29 18:10           ` Arnaldo Carvalho de Melo
2019-08-29 18:50             ` Jakub Kicinski
2019-08-30  6:47           ` Greg Kroah-Hartman
2019-08-30  9:01             ` Toke Høiland-Jørgensen
2019-08-28 21:03 ` [PATCH bpf-next 05/10] tools/bpf: add libbpf_map_type_(from|to)_str helpers Julia Kartseva
2019-08-28 21:03 ` [PATCH bpf-next 06/10] tools/bpf: add libbpf_attach_type_(from|to)_str Julia Kartseva
2019-08-28 21:03 ` [PATCH bpf-next 07/10] selftests/bpf: extend test_section_names with type_(from|to)_str Julia Kartseva
2019-08-28 21:03 ` [PATCH bpf-next 08/10] selftests/bpf: rename test_section_names to test_section_and_type_names Julia Kartseva
2019-08-28 21:03 ` [PATCH bpf-next 09/10] tools/bpftool: use libbpf_(prog|map)_type_to_str helpers Julia Kartseva
2019-08-28 21:03 ` [PATCH bpf-next 10/10] tools/bpftool: use libbpf_attach_type_to_str helper Julia Kartseva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190829065151.GB30423@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=hex@fb.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=rdna@fb.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).