Re: Process for cherry-picking patches from other projects

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 13 May 2022, Juergen Gross wrote:
> On 13.05.22 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?
> > 
> > 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.
> 
> IMO we should add another tag for that purpose, e.g.:
> 
> File-origin: <repository> <tag> <path> [# <local-path>]
> 
> Specifying the repository the file(s) are coming from, the tag (e.g. a
> tagged version, or the top git commit), and the path of the original
> file(s) in that repository (<path> could either be a common directory
> of multiple files, or a single file; multiple "File-origin:" tags should
> be possible). In case the file is being renamed locally, its new name
> can be added as <local-path>.

+1

> This variant should be used to add _new_ files to Xen. In case of
> updating a file which has seem lots of commits since its last update or
> introduction, it might be easier to just use the "File-origin:" tag,
> probably with a note below the "---" marker that listing more than <x>
> patches (x > 10?) or splitting into more than <x> patches would be
> just useless work (common sense should apply here, especially regarding
> the readability of the patch and the related review effort).

+1