* Incorrect Author on patch @ 2018-04-25 15:02 Evan Lloyd 2018-04-25 21:14 ` Laszlo Ersek 0 siblings, 1 reply; 6+ messages in thread From: Evan Lloyd @ 2018-04-25 15:02 UTC (permalink / raw) To: edk2-devel (edk2-devel@lists.01.org), ruiyu.ni@intel.com Hi Ruiyu. When we look at the edk2 git log, or GitHub https://github.com/tianocore/edk2/commit/ee4dc24f57c32a445e7c747396c9bfbd8b221568 we see that Sami's AcpiView patch shows you as the Author. I'm not sure what might have caused that (and it is obviously accidental), but it is a little unfortunate in that the commit doesn't show up on Sami's GitHub stats. Fortunately, this is not currently significant for our organisation, although I'm sure Sami would prefer to have the credit. This is a trivial matter, but you may wish to understand what caused it so that you don't accidentally upset someone for whom the stats are significant. Regards, Evan Evan Lloyd | Technical Lead for Windows on Arm | Arm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . m. +44 (0)7825256132 110 Fulbourn Road, Cambridge, CB1 9NJ Arm.com IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Incorrect Author on patch 2018-04-25 15:02 Incorrect Author on patch Evan Lloyd @ 2018-04-25 21:14 ` Laszlo Ersek 2018-05-02 12:46 ` Evan Lloyd 0 siblings, 1 reply; 6+ messages in thread From: Laszlo Ersek @ 2018-04-25 21:14 UTC (permalink / raw) To: Evan Lloyd, ruiyu.ni@intel.com; +Cc: edk2-devel (edk2-devel@lists.01.org) On 04/25/18 17:02, Evan Lloyd wrote: > Hi Ruiyu. > When we look at the edk2 git log, or GitHub https://github.com/tianocore/edk2/commit/ee4dc24f57c32a445e7c747396c9bfbd8b221568 > we see that Sami's AcpiView patch shows you as the Author. > I'm not sure what might have caused that (and it is obviously accidental), but it is a little unfortunate in that the commit doesn't show up on Sami's GitHub stats. > Fortunately, this is not currently significant for our organisation, although I'm sure Sami would prefer to have the credit. > This is a trivial matter, but you may wish to understand what caused it so that you don't accidentally upset someone for whom the stats are significant. Right, this occurred at least one other time as well: see commit 8b5c80e0296c ("MdeModulePkg/UefiBootManagerLib: fix AddLoadOptionVariable docs/prototype", 2018-04-23). Ray pushed the patch (so the Committer field is certainly right), but Ray's name+email replaced mine in the Author field. I had noticed that earlier, but now I'm seeing it as a pattern. I believe this is a tooling issue. I notice the following bit on the commit message: Change-Id: I8a609d6502b6f8929b2f568acaa147065003b6f4 I certainly didn't post the patch with that, and I doubt Ray added it manually. So, whatever tool Ray used to handle the patch lost the authorship information. And, I see the exact same kind of tag, namely Change-Id: Ifa23dc80ab8ab042c56e88424847e796a8122a7c on commit ee4dc24f57c3 ("ShellPkg: Add acpiview tool to dump ACPI tables", 2018-04-23), which you mention. ... In fact, my patch happens to be the direct ancestor of Sami's, in the git history, and their commit times are just ~3 minutes apart. I'm quite certain Ray has started using a new tool. For example, commit bc2288f59ba2 ("UefiCpuPkg/MpInitLib: put mReservedApLoopFunc in executable memory", 2018-03-08) was also committed by Ray, *but* Jian's authorship was preserved fine. (No "Change-Id" either.) ... Oh... it looks like those Change-Id's were added by Gerrit: https://git.eclipse.org/r/Documentation/user-changeid.html And then, please look at this: https://gerrit-review.googlesource.com/Documentation/error-invalid-author.html For every pushed commit Gerrit verifies that the e-mail address of the author matches one of the registered e-mail addresses of the pushing user. If this is not the case pushing the commit fails with the error message "invalid author". This policy can be bypassed by having the access right 'Forge Author'. Uh, what?... Gerrit says "invalid author" if Ray pushes a patch that wasn't authored by himself? And the option to override that is called "forge" author? O_o Anyway, the page continues, If pushing to Gerrit fails with the error message "invalid author" and somebody else is author of the commit for which the push fails, then you have no permissions to forge the author identity. In this case you may contact the project owner to request the access right '+1 Forge Author Identity' in the 'Forge Identity' category or ask the maintainer to commit this change on the author’s behalf. Ray, if you absolutely must use Gerrit, please make sure that you have the '+1 Forge Author Identity' access right. IMO, we maintainers are responsible for preserving git metadata the best we can. (For example, if a patch is applied from the mailing list with "git am", it preserves the authorship information -- the documentation says, 'The commit author name is taken from the "From: " line of the message, and commit author date is taken from the "Date: " line of the message.') Thank you! Laszlo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Incorrect Author on patch 2018-04-25 21:14 ` Laszlo Ersek @ 2018-05-02 12:46 ` Evan Lloyd 2018-05-02 13:40 ` Laszlo Ersek 2018-05-02 15:20 ` Gao, Liming 0 siblings, 2 replies; 6+ messages in thread From: Evan Lloyd @ 2018-05-02 12:46 UTC (permalink / raw) To: Laszlo Ersek, ruiyu.ni@intel.com; +Cc: edk2-devel (edk2-devel@lists.01.org) One obvious way of precluding this sort of problem would be to move to using the pull request mechanism on GitHub, rather than requiring maintainers to play with upstreaming local patches. I can well understand why it would be useful to use Gerrit as a means of reviewing a patch - actually a brilliant idea, but it does introduce problems. If, post review, the merge were to be from a pull request then there would be no risk of "meta-data corruption". Regards Evan > -----Original Message----- > From: Laszlo Ersek <lersek@redhat.com> > Sent: 25 April 2018 22:15 > To: Evan Lloyd <Evan.Lloyd@arm.com>; ruiyu.ni@intel.com > Cc: edk2-devel (edk2-devel@lists.01.org) <edk2-devel@lists.01.org> > Subject: Re: [edk2] Incorrect Author on patch > > On 04/25/18 17:02, Evan Lloyd wrote: > > Hi Ruiyu. > > When we look at the edk2 git log, or GitHub > > > https://github.com/tianocore/edk2/commit/ee4dc24f57c32a445e7c747396c > 9b > > fbd8b221568 we see that Sami's AcpiView patch shows you as the Author. > > I'm not sure what might have caused that (and it is obviously accidental), but > it is a little unfortunate in that the commit doesn't show up on Sami's GitHub > stats. > > Fortunately, this is not currently significant for our organisation, although I'm > sure Sami would prefer to have the credit. > > This is a trivial matter, but you may wish to understand what caused it so that > you don't accidentally upset someone for whom the stats are significant. > > Right, this occurred at least one other time as well: see commit > 8b5c80e0296c ("MdeModulePkg/UefiBootManagerLib: fix > AddLoadOptionVariable docs/prototype", 2018-04-23). Ray pushed the patch > (so the Committer field is certainly right), but Ray's name+email replaced mine > in the Author field. I had noticed that earlier, but now I'm seeing it as a pattern. > > I believe this is a tooling issue. I notice the following bit on the commit > message: > > Change-Id: I8a609d6502b6f8929b2f568acaa147065003b6f4 > > I certainly didn't post the patch with that, and I doubt Ray added it manually. > So, whatever tool Ray used to handle the patch lost the authorship > information. > > And, I see the exact same kind of tag, namely > > Change-Id: Ifa23dc80ab8ab042c56e88424847e796a8122a7c > > on commit ee4dc24f57c3 ("ShellPkg: Add acpiview tool to dump ACPI tables", > 2018-04-23), which you mention. > > ... In fact, my patch happens to be the direct ancestor of Sami's, in the git > history, and their commit times are just ~3 minutes apart. I'm quite certain Ray > has started using a new tool. > > For example, commit bc2288f59ba2 ("UefiCpuPkg/MpInitLib: put > mReservedApLoopFunc in executable memory", 2018-03-08) was also > committed by Ray, *but* Jian's authorship was preserved fine. (No "Change- > Id" either.) > > ... Oh... it looks like those Change-Id's were added by Gerrit: > > https://git.eclipse.org/r/Documentation/user-changeid.html > > And then, please look at this: > > https://gerrit-review.googlesource.com/Documentation/error-invalid- > author.html > > For every pushed commit Gerrit verifies that the e-mail address of > the author matches one of the registered e-mail addresses of the > pushing user. If this is not the case pushing the commit fails with > the error message "invalid author". This policy can be bypassed by > having the access right 'Forge Author'. > > Uh, what?... Gerrit says "invalid author" if Ray pushes a patch that wasn't > authored by himself? And the option to override that is called "forge" author? > O_o > > Anyway, the page continues, > > If pushing to Gerrit fails with the error message "invalid author" > and somebody else is author of the commit for which the push fails, > then you have no permissions to forge the author identity. In this > case you may contact the project owner to request the access right > '+1 Forge Author Identity' in the 'Forge Identity' category or ask > the maintainer to commit this change on the author’s behalf. > > Ray, if you absolutely must use Gerrit, please make sure that you have the '+1 > Forge Author Identity' access right. IMO, we maintainers are responsible for > preserving git metadata the best we can. > > (For example, if a patch is applied from the mailing list with "git am", it > preserves the authorship information -- the documentation says, 'The commit > author name is taken from the "From: " line of the message, and commit > author date is taken from the "Date: " line of the message.') > > Thank you! > Laszlo IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Incorrect Author on patch 2018-05-02 12:46 ` Evan Lloyd @ 2018-05-02 13:40 ` Laszlo Ersek 2018-05-02 18:31 ` Rebecca Cran 2018-05-02 15:20 ` Gao, Liming 1 sibling, 1 reply; 6+ messages in thread From: Laszlo Ersek @ 2018-05-02 13:40 UTC (permalink / raw) To: Evan Lloyd, ruiyu.ni@intel.com; +Cc: edk2-devel (edk2-devel@lists.01.org) On 05/02/18 14:46, Evan Lloyd wrote: > One obvious way of precluding this sort of problem would be to move to > using the pull request mechanism on GitHub, rather than requiring > maintainers to play with upstreaming local patches. In my opinion: - *git* pull requests: yes, - *github* pull requests: please no. We discussed this a few years (?) ago, and I believe the outcome was that pulling remote branches was fine, as long as: (a) the location to pull from was noted in the cover letter of a patch series, or in a separate pull request emailed to the list, and (b) the maintainer pulling the remote branch verified that the patches reviewed on the list were formatted from the commits on the branch being pulled. The remote branch being pulled may well reside on github, but the review must occur on the list (not on the GitHub web UI), and the actual fetch & merge actions must be carried out by a maintainer locally in their work environment, from where they are supposed to push the new commits to the central repo. In other words, we must not start relying on GitHub tools for either patch reviews or for generating merge commits (or any other kinds of commits). > I can well understand why it would be useful to use Gerrit as a means > of reviewing a patch - actually a brilliant idea, (actually, *not* a brilliant idea, but that's just my opinion :) ) > but it does introduce problems. If, post review, the merge were to be > from a pull request then there would be no risk of "meta-data > corruption". Agreed 100% about "no risk of meta-data corruption". However there is a new risk, namely that of getting unreviewed code into the tree. See requirement (b). And I can imagine that such verification is more trouble for some maintainers than simply applying the patches from the list. Basically, the way I would do it, is: - identify the branch fork-off point from the pull request, - create a local branch at that point, - apply the patches from the mailing list to the local branch, - fetch the remote branch, - format the patches from the local branch, - format the patches from the remote branch, - compare the two sets of locally-formatted patches, - eyeball the results. Local reformatting of the patches applied from the mailing list is necessary because formatting options (such as context size, file order, diff algorithm, subject prefix) affect the comparison. And, simply git-diffing the commits on the parallel branches isn't sufficient, because it doesn't compare authorship or even commit messages. In other projects, pulling from someone basically means letting that someone commit to the project unsupervised. So it's a position of trust. Hence signed pull requests. And those people that submit the pull requests, they certainly need to apply the "leaf" patches from mailing lists, from other contributors, after review. All in all, I don't think there's a way around applying patches intact from the mailing list. Whatever workflow we choose, that action will be part of that workflow. Thanks Laszlo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Incorrect Author on patch 2018-05-02 13:40 ` Laszlo Ersek @ 2018-05-02 18:31 ` Rebecca Cran 0 siblings, 0 replies; 6+ messages in thread From: Rebecca Cran @ 2018-05-02 18:31 UTC (permalink / raw) To: Laszlo Ersek, Evan Lloyd, ruiyu.ni@intel.com Cc: edk2-devel (edk2-devel@lists.01.org) On 5/2/2018 7:40 AM, Laszlo Ersek wrote: > On 05/02/18 14:46, Evan Lloyd wrote: >> I can well understand why it would be useful to use Gerrit as a means >> of reviewing a patch - actually a brilliant idea, > (actually, *not* a brilliant idea, but that's just my opinion :) ) *Please* not Gerrit. If we're going to use a code review system, please let us choose Phabricator. It has a much nicer user interface. You can see an example of the review requests it creates at https://reviews.freebsd.org/differential/ . -- Rebecca ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Incorrect Author on patch 2018-05-02 12:46 ` Evan Lloyd 2018-05-02 13:40 ` Laszlo Ersek @ 2018-05-02 15:20 ` Gao, Liming 1 sibling, 0 replies; 6+ messages in thread From: Gao, Liming @ 2018-05-02 15:20 UTC (permalink / raw) To: Evan Lloyd, Laszlo Ersek, Ni, Ruiyu; +Cc: edk2-devel (edk2-devel@lists.01.org) Evan: I agree this is a mistake in edk2 project. We mix the operation in edk2 project and our internal project. We will double check the patch and avoid such case happen again. Thanks Liming > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Evan Lloyd > Sent: Wednesday, May 2, 2018 8:46 PM > To: Laszlo Ersek <lersek@redhat.com>; Ni, Ruiyu <ruiyu.ni@intel.com> > Cc: edk2-devel (edk2-devel@lists.01.org) <edk2-devel@lists.01.org> > Subject: Re: [edk2] Incorrect Author on patch > > One obvious way of precluding this sort of problem would be to move to using the pull request mechanism on GitHub, rather than > requiring maintainers to play with upstreaming local patches. I can well understand why it would be useful to use Gerrit as a means of > reviewing a patch - actually a brilliant idea, but it does introduce problems. If, post review, the merge were to be from a pull request > then there would be no risk of "meta-data corruption". > > Regards > Evan > > > -----Original Message----- > > From: Laszlo Ersek <lersek@redhat.com> > > Sent: 25 April 2018 22:15 > > To: Evan Lloyd <Evan.Lloyd@arm.com>; ruiyu.ni@intel.com > > Cc: edk2-devel (edk2-devel@lists.01.org) <edk2-devel@lists.01.org> > > Subject: Re: [edk2] Incorrect Author on patch > > > > On 04/25/18 17:02, Evan Lloyd wrote: > > > Hi Ruiyu. > > > When we look at the edk2 git log, or GitHub > > > > > https://github.com/tianocore/edk2/commit/ee4dc24f57c32a445e7c747396c > > 9b > > > fbd8b221568 we see that Sami's AcpiView patch shows you as the Author. > > > I'm not sure what might have caused that (and it is obviously accidental), but > > it is a little unfortunate in that the commit doesn't show up on Sami's GitHub > > stats. > > > Fortunately, this is not currently significant for our organisation, although I'm > > sure Sami would prefer to have the credit. > > > This is a trivial matter, but you may wish to understand what caused it so that > > you don't accidentally upset someone for whom the stats are significant. > > > > Right, this occurred at least one other time as well: see commit > > 8b5c80e0296c ("MdeModulePkg/UefiBootManagerLib: fix > > AddLoadOptionVariable docs/prototype", 2018-04-23). Ray pushed the patch > > (so the Committer field is certainly right), but Ray's name+email replaced mine > > in the Author field. I had noticed that earlier, but now I'm seeing it as a pattern. > > > > I believe this is a tooling issue. I notice the following bit on the commit > > message: > > > > Change-Id: I8a609d6502b6f8929b2f568acaa147065003b6f4 > > > > I certainly didn't post the patch with that, and I doubt Ray added it manually. > > So, whatever tool Ray used to handle the patch lost the authorship > > information. > > > > And, I see the exact same kind of tag, namely > > > > Change-Id: Ifa23dc80ab8ab042c56e88424847e796a8122a7c > > > > on commit ee4dc24f57c3 ("ShellPkg: Add acpiview tool to dump ACPI tables", > > 2018-04-23), which you mention. > > > > ... In fact, my patch happens to be the direct ancestor of Sami's, in the git > > history, and their commit times are just ~3 minutes apart. I'm quite certain Ray > > has started using a new tool. > > > > For example, commit bc2288f59ba2 ("UefiCpuPkg/MpInitLib: put > > mReservedApLoopFunc in executable memory", 2018-03-08) was also > > committed by Ray, *but* Jian's authorship was preserved fine. (No "Change- > > Id" either.) > > > > ... Oh... it looks like those Change-Id's were added by Gerrit: > > > > https://git.eclipse.org/r/Documentation/user-changeid.html > > > > And then, please look at this: > > > > https://gerrit-review.googlesource.com/Documentation/error-invalid- > > author.html > > > > For every pushed commit Gerrit verifies that the e-mail address of > > the author matches one of the registered e-mail addresses of the > > pushing user. If this is not the case pushing the commit fails with > > the error message "invalid author". This policy can be bypassed by > > having the access right 'Forge Author'. > > > > Uh, what?... Gerrit says "invalid author" if Ray pushes a patch that wasn't > > authored by himself? And the option to override that is called "forge" author? > > O_o > > > > Anyway, the page continues, > > > > If pushing to Gerrit fails with the error message "invalid author" > > and somebody else is author of the commit for which the push fails, > > then you have no permissions to forge the author identity. In this > > case you may contact the project owner to request the access right > > '+1 Forge Author Identity' in the 'Forge Identity' category or ask > > the maintainer to commit this change on the author’s behalf. > > > > Ray, if you absolutely must use Gerrit, please make sure that you have the '+1 > > Forge Author Identity' access right. IMO, we maintainers are responsible for > > preserving git metadata the best we can. > > > > (For example, if a patch is applied from the mailing list with "git am", it > > preserves the authorship information -- the documentation says, 'The commit > > author name is taken from the "From: " line of the message, and commit > > author date is taken from the "Date: " line of the message.') > > > > Thank you! > > Laszlo > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the > intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, > or store or copy the information in any medium. Thank you. > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-05-02 18:31 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-04-25 15:02 Incorrect Author on patch Evan Lloyd 2018-04-25 21:14 ` Laszlo Ersek 2018-05-02 12:46 ` Evan Lloyd 2018-05-02 13:40 ` Laszlo Ersek 2018-05-02 18:31 ` Rebecca Cran 2018-05-02 15:20 ` Gao, Liming
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox