Re: Process for cherry-picking patches from other projects

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.05.2022 16:33, George Dunlap wrote:
> Starting a new thread to make it clear that we’re discussing a wider policy 
> here.
> 
> This question is aimed at Jan and Andy in particular, as I think they’ve 
> probably done the most of this; so I’m looking to them to find out what our 
> “standard practice” is.
> 
> There have recently been some patches that Bertrand has submitted which pull 
> in code from Linux ("[PATCH 1/3] xen/arm: Sync sysregs and cpuinfo with Linux 
> 5.18-rc3”), which has caused a discussion between him, Julien, and Stefano 
> about the proper way to do such patches.
> 
> The “Origin:” tag section of xen.git/docs/process/sending-patches.pandoc 
> suggests that there are some standards, but doesn’t spell them out.
> 
> The questions seem to be:
> 
> 1) When doing this kind of update, is it permissible to send a single patch 
> which “batches” several upstream commits together, or should each patch be 
> backported individually?
> 
> 2) If “batches” are permissible, when?  When would individual patches be 
> preferred?
> 
> 3) For “batch updates”, what tags are necessary?  Do we need to note the 
> changesets of all the commits, and if so, do we need multiple “Origin” tags?  
> Do we need to include anything from the original commits — commit messages?  
> Signed-off-by’s?

Having seen the various other replies, I'd like to support all views
along the lines of "it depends". I don't think we have formal rules
applicable all over our code base. One model might be used in one
place (and then preferably that model would be followed there), while
another model might make more sense in a 2nd case.

> And a related question:
> 
> 4) When importing an entire file from an upstream like Linux, what tags do we 
> need?
> 
> My recollection is that we often to a “accumulated patch” to update, say, the 
> Kconfig tooling; so it seems like the answer to this is sometimes “yes”.
> 
> It seems to me that in a case where you’re importing a handful of patches — 
> say 5-10 — that importing them one-by-one might be preferred; but in this 
> case, since the submission was already made as a batch, I’d accept having it 
> as a batch.
> 
> I think if I were writing this patch, I’d make a separate “Origin” tag for 
> each commit.
> 
> I wouldn’t include the upstream commit messages or S-o-b’s; I would write my 
> own commit message summarizing why I’m importing the commits, then have the 
> ‘origin’ tags, then my own S-o-b to indicate that I am attesting that it 
> comes from an open-source project (and for whatever copyright can be asserted 
> on the commit message and the patch as a collection).
> 
> And for #4, I would do something similar: I would write my own commit message 
> describing what the file is for and why we’re importing it; have the Origin 
> tag point to the commit at the point I took the file; and my own S-o-b.

Hmm. The present rules written down in docs/process/sending-patches.pandoc
are a result of me having been accused of unduly stripping S-o-b (and maybe
a few other) tags. If that was for a real reason (and not just because of
someone's taste), how could it ever be okay to remove S-o-b? (Personally I
agree with what you propose, it just doesn't line up with that discussion
we had not all that long ago.)

Jan