On Sun, Nov 25, 2018 at 11:29:14PM +0000, John Levon wrote: > On Sun, Nov 25, 2018 at 10:29:56PM +0100, Luc Van Oostenryck wrote: > > > This is copied from existing patches from sparse: > > https://git.kernel.org/pub/scm/devel/sparse/sparse.git/commit/?id=2f922ba822da324ccd2c201c076ca94d5e910a8a > > https://git.kernel.org/pub/scm/devel/sparse/sparse.git/commit/?id=d32b2f7c202fd27206169ca99da898ca9c20dfab > > Hi Luc, apologies. I did in fact mention this patch was in part from > upstream. No problem. Sorry, but I don't see this in the patch/email itself (and I didn't see a "cover letter" explaining the whole series). > > without giving credit and without respecting the Signed-off-by / > > Developer Certificate of Origin (cfr. https://developercertificate.org/). > > I'm not clear how this isn't covered under part b) here. > > Please clarify exactly what you would like me to do. Hi, The signed-off-by should be like: Signed-off-by: Original Author <author@xxxxxxxxxxx> Signed-off-by: John Levon <levon@xxxxxxxxxxxxxxxxx> That's for the DCO (the idea is to be able to somehow track the origin of the patch and who has possibly modified it). The GIT_AUTHOR should also be preserved. When resending a patch, this can be done by adding in the very first line of the message body a line like: From: Original Author <author@xxxxxxxxxxx> (if the patch is then taken via git-am and some other tools). Putting this DCO question aside, I would find normal that the commit message would contains a small note adding something like: [This patch was originally written by ...] Now, I also think that these patches, touching the sparse's part of smatch, will make things more difficult when/if smatch's tree will be synchronized with sparse's. Even more so if they are slightly different than sparse's upstream. Wouldn't it be better to: 1) ask Dan (smatch's maintainer) if he could take this and this patches in sparse's upstream because they solve this and this problem for you; 2) also submit the ones you wrote yourself to sparse's mailing list so that both smatch and sparse can benefit from the improvement? -- Luc Van Oostenryck
