On 06/24/15 09:25, Gao, Liming wrote: > Laszlo: > Ok. If so, people can contact the first S-o-b if they find any issue in > this patch. Right?
Yes. In particular, the semi-official git-svn mirror retains the generic git property that "committer" and "author" are maintained separately. Although SVN (which is the master repo) does not maintain these metadata separately -- there's only "committer" --, Jordan's commit migration script passes the "--use-log-author" option to git-svn, and then git-svn sets the git commit fields as follows: - "committer" comes from the SVN committer, - "author" is set from the first "From:" or "Signed-off-by:" line found in the commit message. "git log" and "git blame" will report the "author" field, so whoever is looking for a code line's (or a patch's) author will find him, not the committer. Direct SVN users can consult the first Signed-off-by: tag found in the commit message. (If you are curious about the distinction between the "From:" and "Signed-off-by:" lines: - "From:" is emitted by "git format-patch" automatically when the "author" meta-datum of a patch is different from the git user's identity (given by user.name, user.email in .gitconfig). That is, "From:" is based on git metadata. The authorship is set by "git commit --author=...", or "git am" -- from a patch email --, or by simple "git commit" (using the user's identity). - "Signed-off-by:" is part of the commit message. It is added either manually, or appended by "git commit -s", or generated by "git format-patch -s".) > Besides, I still want to clarify below two. > 1. Any changes made by the submitter should be noted above the submitter's > Signed-off-by line. > [Liming] It means the description is required to separate the changes from > the different S-o-b. Yes. Normally, the submitter / maintainer is not expected to make any changes to a patch that he forwards or receives. If larger updates are necessary, then the original author should be asked to post a new version of the patch. However, sometimes the changes that are needed are trivial. Reword the commit message slightly, fix a typo in the patch, fix indentation, update a comment, and so on. In these cases a full round-trip with the original author is sometimes deemed overkill, so the submitter / maintainer fixes up the patch himself, before committing it or posting it. The additional changes (which should really be minimal) are then noted *below* the original author's S-o-b (because those changes occurred later), and should be signed off by the submitter separately. You can see an example in SVN r17690. > 2. If git is being used to prepare the patches, the git author of the commit > corresponding to the patch should be owned by the original author (git commit > --author). > [Liming] It means the patch must be prepared by the author? No. Let me give you two workflow examples. I. (1) Alice posts some patches to edk2-devel. Her patch series is almost complete, but it misses a patch at the end. In the cover letter email, she explains why that patch is missing, and asks for ideas for implementing the missing bit. (2) Bob responds in email, plus he attaches a rough patch (only formatted with "git diff", that is, no commit message) that explains his idea. (3) Alice applies this patch to her tree with the "patch" utility. Her working tree is changed, but nothing else. She then updates the working tree a little bit, and then commits the changes as a regular commit. She uses the command git commit --author='Bob <...>' --signoff This will - start the commit message editor with Alice's signoff immediately added to the end - set the authorship of the commit as Bob, in the git metadata Then Alice writes a commit message, and also *prepends* Bob's S-o-b manually to her own, at the end of the commit message. What she ends up with is: - authorship: Bob's - commit message: what the patch does, worded by Alice - first signoff: Bob's - [optionally: slight code changes by Alice] - second signoff: Alice's For edk2, both signoffs can be preceded by the Contributed-under tag. (4) Alice formats and posts the entire patch series. In the patch emails, and -- after the maintainer applies the patches -- in the repository too, it will be clear that the primary author of the last patch is Bob. II. Same as the above, except in (2), Bob doesn't send a raw "git diff", but a full patch, coming from a commit in his private tree, formatted with "git format-patch". (This can be an attachment or even a standalone patch email, sent with "git send-email".) In this case, Alice doesn't use the "patch" utility, and she doesn't have to write a commit message of her own. Instead, she saves the patch email to a local file, and runs "git am --signoff EMAIL_FILE", which - applies the patch, - commits it, - grabs Bob's authorship from the email directly (from the From field), - takes the commit message from the email too (which of course contains Bob's signoff to begin with), - and then *appends* Alice's own signoff. Alice can then tweak the patch further (only with minimal changes), and describe her changes between the two signoffs. Ultimately there are many ways to set these things -- for example, if some Signed-off-by: tags are missing across a patch series, one runs "git rebase -i", marks the patches in question as "reword", and then adds the Signed-off-by: tags manually --; what matters is the end result. The end result should be: - "From:" (ie. git authorship meta-datum) and the first S-o-b should reflect the primary author of the patch - If a different person modifies (slightly) or forwards or reposts the patch, then his S-o-b should be appended. - (If a project uses PULL requests, then whoever is pulled from (ie. sub-maintainers) add their S-o-b's as soon as they acquire the patches inside their own trees, by any means -- pulling themselves, or git-am...) I'm afraid this stuff cannot be explained really well in writing. You have to become an everyday git user first, and then it will come to you naturally. (It doesn't mean that I don't make mistakes, but at least I make those mistakes routinely! :)) Thanks Laszlo > > Thanks > Liming > -----Original Message----- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Wednesday, June 24, 2015 2:57 PM > To: Gao, Liming > Cc: edk2-devel@lists.sourceforge.net; Kinney, Michael D; Roy Franz > Subject: Re: [edk2] [PATCH] MdePkg: Describe submission of a patch authored > by someone else > > On 06/24/15 03:36, Gao, Liming wrote: >> This rule means the submitter is also Signed-off-by. Right? > > Yes. > >> I originally understand Signed-off-by means the patch authors, not >> submitter. Could you let me why add this new rule? > > In the particular case that inspired this documentation patch, I and Roy (in > this chronological order) are both authors of the (code) patch. So that makes > it unavoidable to list both our S-o-b tags. > > However, in the general case, whoever forwards or reposts, with or without > code / commit msg editing, a patch, needs to add an S-o-b. > "Principal authorship" belongs with the first S-o-b. (Also relevant: > "git svn rebase --use-log-author".) > > To my knowledge, the Signed-off-by and other similar tags originate from the > Linux kernel workflow. Please refer to: > > https://www.kernel.org/doc/Documentation/SubmittingPatches > > section "11) Sign your work". That should explain the idea better than I > could. > > See also: > > http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for > > [...] It is used to say that you certify that you have created the > patch in question, or that you certify that to the best of your > knowledge, it was created under an appropriate open-source license, > or that it has been provided to you by someone else under those > terms. This can help establish a chain of people who take > responsibility for the copyright status of the code in question > [...] > > Thanks > Laszlo > >> -----Original Message----- >> From: Roy Franz [mailto:roy.fr...@linaro.org] >> Sent: Wednesday, June 24, 2015 2:36 AM >> To: edk2-devel@lists.sourceforge.net; ler...@redhat.com; Kinney, >> Michael D >> Subject: [edk2] [PATCH] MdePkg: Describe submission of a patch >> authored by someone else >> >> Add a description of how to describe the authorship of a patch that is >> submitted by someone other than the original author. >> Add mention of git format-patch --stat=120 option for generating more useful >> patch names in diffstat. >> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Roy Franz <roy.fr...@linaro.org> >> --- >> MdePkg/Contributions.txt | 11 ++++++++++- >> 1 file changed, 10 insertions(+), 1 deletion(-) >> >> diff --git a/MdePkg/Contributions.txt b/MdePkg/Contributions.txt index >> f87cbd7..98de958 100644 >> --- a/MdePkg/Contributions.txt >> +++ b/MdePkg/Contributions.txt >> @@ -67,7 +67,16 @@ Patch content inline or attached >> * The first line of commit message is taken from the email's subject >> line following [PATCH]. The remaining portion of the commit message >> is the email's content until the '---' line. >> -* git format-patch is one way to create this format >> +* git format-patch is one way to create this format. In order to get >> + useful path names in the diffstat, the "--stat=120" option should >> + be used. >> +* If a patch is being submitted by someone other than the orginal >> + author, then the orginal author's Signed-off-by/Contributed-under >> +lines >> + should be first, followed by the Signed-off-by/Contributed-under >> +lines >> + of the patch submitter. Any changes made by the submitter should >> +be >> + noted above the submitter's Signed-off-by line. If git is being >> +used >> + to prepare the patches, the git author of the commit corresponding >> +to >> + the patch should be owned by the original author (git commit --author). >> >> === Definitions for sample patch email === >> >> -- >> 2.1.4 >> >> >> ---------------------------------------------------------------------- >> -------- Monitor 25 network devices or servers for free with >> OpManager! >> OpManager is web-based network management software that monitors >> network devices and physical & virtual servers, alerts via email & sms >> for fault. Monitor 25 devices for free with no restriction. Download >> now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/edk2-devel >> > ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
