[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Process for cherry-picking patches from other projects
On 16.05.22 15:12, George Dunlap wrote:
On May 13, 2022, at 3:52 PM, Juergen Gross <JGross@xxxxxxxx> 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>.
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).
You don’t mention what to do about SoB’s — I assume you agree with my assessment
above, that a single SoB from the submitter of the patch to Xen, asserting that they’re satisfied
that all of the code has been asserted by other people as having a suitable license, is sufficient.
Yes.
In which case, barring a contradiction from Andy or Jan as to our standard practice, I
think that we don’t need to collect SoBs from the original commits; a single
SoB by Bertrand (or whomever) that it all comes from Linux and that suitable SoBs can
be tracked down should it become necessary, will be sufficient.
Yes, this is the idea by specifying a tag of the source repository.
Using the correct git commands it should always be possible to get
the complete list of SoBs for an imported file.
Juergen
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
|
