[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Process for cherry-picking patches from other projects
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |