Re: [PATCH 05/18] sparse: correctly handle "-D foo" and "-U foo". The former is from sparse upstream, but they didn't fix the latter for some reason.

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 <[email protected]>
	Signed-off-by: John Levon <[email protected]>
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 <[email protected]>
(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