Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

["Laszlo Ersek" <lersek@redhat.com>]

On 05/11/20 22:09, Bret Barkelew wrote:
> As a counterpoint: if we force a new branch or force push on every tweak, we lose the “thread� of discussion on what caused the change,

This is a github.com limitation.

And the email archive mitigates it.

In the current process, when I review v2 of a 10-part series, I have one
Thunderbird window open with the v1 thread, containing both the v1
patches and my (and others') review comments given for them.

(I open the new window by right-clicking the v1 blurb, and then
selecting "open message in new window". Then I navigate between the
messages of the v1 thread with the "f" and "b" hotkeys. The "scope" of
the new window is set to the v1 thread, recursively, when I open the new
window like that, and so "f" and "b" just do the right thing.)

In another window, to the right side, I run "git-range-diff", to
interdiff the v1 patches (patch by patch) with the v2 patches. (An
interdiff is a diff of diffs.) Importantly, the interdiff also
highlights commit message differences.

I verify that all the feedback comments from the v1 thread have been
addressed (per patch), and also that any otherwise "uncalled-for"
changes in v2 are in fact justified. (The contributor may have
justifiedly implemented further changes than what I requested under v1.)
This is also the reason why I meticulously number my feedback comments,
as I'm going to require a complete (one by one) coverage in the next
version of the patch set. (Except for those comments of course that the
contributor successfully refutes.)

When the v2 series has different structure from v1, then git-range-diff
is not as helpful -- in that case, I compare only a subset of the
patches like described above, and the entirely new patches in v2 I have
to review from zero.

The entire process depends on having unfettered access to comments given
for *any* earlier version of the patch set (it's not uncommon that I
refer back to v(n-3) or v(n-2) when reviewing v(n)), with those comments
being tightly bound (for display and for re-reading) to their subject
patches.

The github webui destroys (at least visually) the comments given before
a force-push. I can't fathom how incremental reviews can work on
github.com *at all*, in other projects. Hence my earlier suggestion to
use new pull requests rather than force-pushes.

But the mailing list archive generated by the webhook will solve this
completely -- I will use that list as a primary review support tool (for
v2, v3, ...), not only as an archive.


... After all, I guess I could reformulate like this: it's not my intent
to prevent people from pushing incremental fixups *temporarily*; I'm
only saying I will ignore those patches, and I will review only the next
full version of the branch.


My concern that does persist is this: "it runs the risk that the
maintainer responsible for ultimately merging the series ends up
actually merging the incremental (= "fixup") patches in isolation
(without squashing them)".

The git history should neither be littered with fixup patches, nor
contain huge squashes. The structure of a patch series is a first class
trait; it is an aspect to iterate upon, when a branch is being
contributed. The tooling should support that. (And the list traffic
generated by the webhook does.)

For instance, the last time I've given feedback regarding patch series
structure was just an hour ago, under the series "[PATCH V4 00/27]
Disabling safe string constraint assertions". I requested moving a hunk
from patch#1 to patch#26. Having the hunk in patch#1 does not break
bisection, and it's irrelevant for the end-state after the whole series
is applied (the end-state is the same). But the hunk still doesn't
*belong* in patch#1 -- wherever we add a new bit to a bitmask PCD
(patch#26), the UNI file (= documentation) udpate belongs in the exact
same patch.

> what changed as a result, and the easy hook for the original change requester to reply directly to the change as is.

No matter what I say about an incremental/fixup patch in isolation,
things can easily go wrong when the contributor squashes the fixup into
the more substantial patch that needs the fixup. Not to mention any
commit message updates on the more substantial patch, as necessitated by
the fixup. So I'll have to review the next full version of the topic
branch anyway, with git-range-diff, and compare the interdiff against my
earlier feedback.

Thanks!
Laszlo


> 
> - Bret
> 
> From: Laszlo Ersek via groups.io<mailto:lersek=redhat.com@groups.io>
> Sent: Monday, May 11, 2020 12:39 PM
> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
> Subject: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process
> 
> On 05/09/20 04:59, Michael D Kinney wrote:
>> Hello,
>>
>> This is a proposal to change from the current email-based code review process to
>> a GitHub pull request-based code review process for all repositories maintained
>> in TianoCore.  The current email-based code review process and commit message
>> requirements are documented in Readme.md or Readme.rst at the root of
>> repositories along with a few Wiki pages:
>>
>> * https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FReadMe.rst&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586668645&amp;sdata=lVjWRLsBC3xJpyRFeDrGjFhMOzAgi2V3vsAPxj7lIDw%3D&amp;reserved=0
>> * https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FEDK-II-Development-Process&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586668645&amp;sdata=sgAhQxCpyjmzC%2FW%2BFiLLwaF2M8wscBz3k93ne25qUXs%3D&amp;reserved=0
>> * https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FLaszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586668645&amp;sdata=eHP9fcPMw6yjqTU%2B%2BUZ3FZkq8jZeM1LTU6dGTzmFp4Q%3D&amp;reserved=0
>> * https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FCommit-Message-Format&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586668645&amp;sdata=uq8G6nGyLpa7m%2F0fD2pwrcM9uixbKs6SLTge8e77M%2FY%3D&amp;reserved=0
>> * https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FCommit-Signature-Format&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586668645&amp;sdata=Mz8dUn2L8dFwJdlo4LbaIKt2JrWE%2Fn4tBtVWenK%2F8Ck%3D&amp;reserved=0
>>
>> The goal is to post changes by opening a GitHub pull request and perform all
>> code review activity using the GitHub web interface.  This proposal does not
>> change any licenses or commit message requirements.  It does require all
>> developers, maintainers, and reviewers to have GitHub accounts.
>>
>> One requirement that was collected from previous discussions on this topic is
>> the need for an email archive of all patches and code review activities.  The
>> existing GitHub features to produce an email archive were deemed insufficient.
>> A proof of concept of a GitHub webhook has been implemented to provide the email
>> archive service.  This email archive is read-only.  You will not be able to send
>> emails to this archive or reply to emails in the archive.
>>
>> The sections below provide more details on the proposed GitHub pull request
>> based code review process, details on the email archive service, and a set of
>> remaining tasks make the email archive service production quality.  It does not
>> make sense to support both the existing email-based code review and the GitHub
>> pull request-based code review at the same time.  Instead, this proposal is to
>> switch to the GitHub pull request-based code review and retire the email based
>> code review process on the same date.
>>
>> The edk2 repository is using GitHub pull requests today to run automated
>> CI checks on the code changes and allows a maintainer to set the `push` label to
>> request the changes to be merged if all CI checks pass.  With this proposal,
>> once the code review is complete and the commit messages have been updated, the
>> same pull request can be used to perform a final set of CI checks and merge the
>> changes into the master branch.
>>
>> I would like to collect feedback on this proposal and the email archive service
>> over the next two weeks with close of comments on Friday May 22, 2020.  If all
>> issues and concerns can be addressed, then I would like to see the community
>> agree to make this change as soon as all remaining tasks are completed.
>>
>> # TianoCore Repositories to enable
>>
>> * [edk2](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586668645&amp;sdata=Jvbl8ypdXIi7U5Jnr3s0TOx6hD54N55mdsbXi9sCznM%3D&amp;reserved=0)
>> * [edk2-platforms](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2-platforms&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586668645&amp;sdata=g8mgGL6B%2FRsvm3935OpZMctOTKUoeHGi8jPuCVKQjbI%3D&amp;reserved=0)
>> * [edk2-non-osi](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2-non-osi&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586668645&amp;sdata=9lrEsZWOpc3wqylKs7yF%2FzxYwZsUUamP3oUrWDWcHCc%3D&amp;reserved=0)
>> * [edk2-test](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2-test&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586668645&amp;sdata=8v205MD3HTYg3yLmGJS3SIDA5um9sVJfOa5CXViZjyU%3D&amp;reserved=0)
>> * [edk2-libc](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2-libc&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586668645&amp;sdata=Tzt293HJzFnGSkh1mUBew8dAsaZ4axWq2ml8UhQ%2FSTI%3D&amp;reserved=0)
>> * [edk2-staging](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2-staging&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586668645&amp;sdata=bcNbt7Y7KoBrcnW4fAc4jbGgJL%2B4lYUkVLhYNo37OiM%3D&amp;reserved=0)
>>
>> # GitHub Pull Request Code Review Process
>>
>> **NOTE**: All steps below use [edk2](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586668645&amp;sdata=Jvbl8ypdXIi7U5Jnr3s0TOx6hD54N55mdsbXi9sCznM%3D&amp;reserved=0) as an
>> example.  Several repositories are supported.
>>
>> ## Author/Developer Steps
>>   * Create a personal fork of [edk2](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586668645&amp;sdata=Jvbl8ypdXIi7U5Jnr3s0TOx6hD54N55mdsbXi9sCznM%3D&amp;reserved=0)
>>
>>     https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Fen%2Fgithub%2Fgetting-started-with-github%2Ffork-a-repo&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=umI3eqOh03qmt9YlPo33ujypu90YwImAvuxh5SlrM%2Bw%3D&amp;reserved=0
>>
>>   * Create a new branch from edk2/master in personal fork of edk2 repository.
>>
>>   * Add set of commits for new feature or bug fix to new branch.  Make sure to
>>     follow the commit message format requirements.  The only change with this
>>     RFC is that the Cc: lines to maintainers/reviewers should **not** be added.
>>     The Cc: lines are still supported, but they should only be used to add
>>     reviewers that do not have GitHub IDs or are not members of TianoCore.
>>
>>   * Push branch with new commits to personal fork
>>   * Create a pull request against TianoCore edk2/master
>>
>>     https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Fen%2Fgithub%2Fcollaborating-with-issues-and-pull-requests%2Fcreating-a-pull-request&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=2GVrQy0FGwd4CCeGveh99HL3zS1ekRfAAaKhhRiOMpU%3D&amp;reserved=0
>>
>>   * If pull request has more than 1 commit, then fill in the pull request title
>>     and decryption information for Patch #0.  Do not leave defaults.
> 
> s/decryption/description/
> 
> (Because I'm assuming this will turn into a wiki article at some point.)
> 
>>
>>   * Do not assign reviewers.  The webhook assigns maintainers and reviewers to
>>     the pull request and each commit in the pull request.
>>
>>   * If maintainers/reviewers provide feedback that requires changes, then make
>>     add commits to the current branch with the requested changes.  Once all
> 
> s/make add/add/
> 
>>     changes are accepted on the current branch, reformulate the patch series and
>>     commit comments as needed for perform a forced push to the branch in the
>>     personal fork of the edk2 repository.  This step may be repeated if multiple
>>     versions of the patch series are required to address all code review
>>     feedback.
> 
> Do I understand correctly that this recommends the contributor first
> push incremental patches on top of the series, then do a rebase
> (squashing updates as necessary) and finally do a force-push, for the
> next round of review?
> 
> To me as a reviewer, that's extra work. I'm used to locally comparing
> the v(n) patch set to v(n+1) with git-range-diff, and/or with some
> personal scripts. I wouldn't encourage incremental patches appended --
> even temporarily -- to the branch, because (a) it's extra review work
> (it requires me to review something that has zero chance to get into the
> git history as-is), and (b) it superficially resembles the
> github.com-specific bad practice called "squash on merge", and (c) it
> runs the risk that the maintainer responsible for ultimately merging the
> series ends up actually merging the incremental (= "fixup") patches in
> isolation (without squashing them).
> 
>>
>>   **OPEN**: How should minimum review period be set?  Labels?
> 
> Not sure about the best tooling. My recommendation would be to require
> reviewers to start providing their feedback within one week.
> 
> One thing that I find important is that a maintainer can signal "I got
> your work in my queue, but I may need more time". And a special case of
> that are automated out-of-office responses. I think they are very
> helpful (when a contributor feels they are bottlenecked on review), but
> I'm not sure how one can configure that via github. I certainly would
> not share my out-of-office times with github. (I set the start/end dates
> in my email infrastructure, at the moment, but the out-of-office
> messages it sends do not contain the dates either, on purpose.)
> 
>>
>> ## TianoCore GitHub Email Archive Webhook Service Steps
>>   * Receive an event that a new pull request was opened
>>   * Evaluate the files modified by the entire pull request and each commit in
>>     the pull request and cross references against `Maintainters.txt` in the root
> 
> s/cross references/cross reference them/ ?
> 
>>     of the repository to assign maintainers/reviewers to the pull request and
>>     each commit in the pull request. Individual commit assignments are performed
>>     by adding a commit comment of the following form:
>>
>>     [CodeReview] Review-request @mdkinney
>>
>>   * Generate and sends git patch review emails to the email archive.  Emails
> 
> s/sends/send/
> 
>>     are also sent to any Cc: tags in the commit messages.
>>
>>   * If the author/developer performs a forced push to the branch in their
>>     personal fork of the edk2 repository, then a new set of patch review emails
>>     with patch series Vx is sent to the email archive and any Cc: tags in commit
>>     messages.
>>
>>   * Receive events associated with all code review activities and generate
>>     and send emails to the email archive that shows all review comments and
>>     all responses closely matching the email contents seen in the current email
>>     based code review process.
>>
>>   * Generate and send email when pull request is merged or closed.
>>
>> ## Maintainer/Reviewer Steps
>>
>>   * Make sure GitHub configuration is setup to 'Watch' the repositories that
>>     you have maintainer ship or review responsibilities and that email
> 
> s/maintainer ship/maintainership/
> 
>>     notifications from GitHub are enabled.  This enables email notifications
>>     when a maintainer/reviewer is assigned to a pull request and individual
>>     commits.
>>
>>     https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Fen%2Fgithub%2Fmanaging-subscriptions-and-notifications-on-github%2Fconfiguring-notifications&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=OlkiyymcQi39P8%2FOJZG4yjh4h%2FHerkHBe5bCSQQFLOU%3D&amp;reserved=0
>>
>>   * Subscribe to the email archive associated with the TianoCore GitHub Email
>>     Archive Webhook Service.
>>
>>     https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fmailman%2Flistinfo%2Ftianocore-code-review-poc&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=q0IuvS318pEkJU2td9xX87oIm0LbSlEvOvhpyOOFrE8%3D&amp;reserved=0
> 
> Important: as the name says ("-poc"), this is a Proof of Concept list,
> for now. Once we're ready to switch over, I'll file an internal ticket
> at RH to either rename the list, or (which is probably better) to create
> a new list (no "-poc" suffix).
> 
> The second option seems more useful because then the webhook development
> / bugfixing (if any) could perhaps occur in parallel to the normal edk2
> workflow.
> 
>>
>>   * Review pull requests and commits assigned by the TianoCore GitHub Email
>>     Archive Webhook Service and use the GitHub web UI to provide all review
>>     feedback.
>>
>>     https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Fen%2Fgithub%2Fcollaborating-with-issues-and-pull-requests%2Freviewing-changes-in-pull-requests&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=51Ljm3wUbBTWT8hcaBD1ZQznSROvAQqnoTzQmD6K%2FLY%3D&amp;reserved=0
>>
>>   * Wait for Author/Developer to respond to all feedback and add commits with
>>     code changes as needed to resolve all feedback.  This step may be repeated
>>     if the developer/author need to produce multiple versions of the patch
>>     series to address all feedback.
> 
> (same question about the incremental fixup patches as above)
> 
>>
>>   * Once all feedback is addressed, add Reviewed-by, Acked-by, and Tested-by
>>     responses on individual commits.  Or add Series-reviewed-by, Series-acked-by,
>>     or Series-Tested-by responses to the entire pull request.
>>
>>   * Wait for Developer/Author to add tags to commit messages in the pull request.
>>
>>   * Perform final review of patches and commit message tags.  If there are not
>>     issues, set the `push` label to run final set of CI checks and auto merge
>>     the pull request into master.
>>
>> # Maintainers.txt Format Changes
>>
>> Add GitHub IDs of all maintainers and reviewers at the end of M: and R: lines
>> in [].  For example:
>>
>>     M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
>>
>> # TianoCore GitHub Email Archive Webhook Service
>>
>> Assign reviewers to commits in a GitHub pull request based on assignments
>> documented in Maintainers.txt and generates an email archive of all pull request
>> and code review activities.
> 
> s/generates/generate/
> 
> (or s/Assign/Assigns/)
> 
>>
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmdkinney%2Fedk2-email-archive-webhook&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=7CJNJMEXrxoynjavmEwjzUyRbfNUIZ3FEG4kDRXvhI4%3D&amp;reserved=0
>>
>> # Email Archive Subscription Service
>>
>> The emails are being delivered to the following RedHat email subscription
>> service.  Please subscribe to receive the emails and to be able to view the
>> email archives.
>>
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fmailman%2Flistinfo%2Ftianocore-code-review-poc&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=q0IuvS318pEkJU2td9xX87oIm0LbSlEvOvhpyOOFrE8%3D&amp;reserved=0
>>
>> The email archives are at this link:
>>
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fmailman%2Fprivate%2Ftianocore-code-review-poc%2Findex.html&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=nedUfkmMmI5T6GtAxQCW4q6xt38%2FezeDYmfq6cpRD0M%3D&amp;reserved=0
>>
>> The following sections show some example pull requests and code reviews to
>> help review the generated emails, their contents, and threading.
>>
>> ## Email Achieve Thread View
>>
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fmailman%2Fprivate%2Ftianocore-code-review-poc%2F2020-May%2Fthread.html%2300289&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=GtrEudehfXiSU6ZwH2zKO35CPPPVk0ctZIzhkpI6DkE%3D&amp;reserved=0
>>
>> ## Example patch series with 1 patch
>>
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fmailman%2Fprivate%2Ftianocore-code-review-poc%2F2020-May%2Fthread.html%2300340&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=ZGpI8%2BzIA9OMFm3pSCc2DQ4F5ZxtDSAXtjdFjD%2BY3NA%3D&amp;reserved=0
>>
>> ## Example patch series with < 10 patches
>>
>> * https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fmailman%2Fprivate%2Ftianocore-code-review-poc%2F2020-May%2Fmsg00289.html&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=JyaUyvYfZD7b%2F2wN%2BpS%2B68b%2BwyKoZ3Rba4ol%2FyahQVU%3D&amp;reserved=0
>> * https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fmailman%2Fprivate%2Ftianocore-code-review-poc%2F2020-May%2Fmsg00030.html&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=bQHIJIQq4Pri8iK3vPxMDMWz%2BKtXcyuPdhr8y7gFpXA%3D&amp;reserved=0
>> * https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fmailman%2Fprivate%2Ftianocore-code-review-poc%2F2020-May%2Fmsg00018.html&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=uMIRGOq%2BVCOSwDzXkG4yueYS4ZJ7BWfsp3Z4%2B9lh6hE%3D&amp;reserved=0
>> * https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fmailman%2Fprivate%2Ftianocore-code-review-poc%2F2020-May%2Fmsg00008.html&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=3CBkdqDxRt4IxtECpWQdKJL%2Bf4HFqqHCXo4loxNTzAE%3D&amp;reserved=0
>>
>> ## Example patch series with > 80 patches
>>
>> * https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fmailman%2Fprivate%2Ftianocore-code-review-poc%2F2020-May%2Fmsg00198.html&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=fDfQnifOMzyzLMdP4xH8koKCiSj7ZiuYyrrSZXTf3d4%3D&amp;reserved=0
>> * https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fmailman%2Fprivate%2Ftianocore-code-review-poc%2F2020-May%2Fmsg00116.html&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=lcxA3tTna%2BdmTpcNMmPlS%2B47llMAcIEjhCEqxV7TDOc%3D&amp;reserved=0
>> * https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fmailman%2Fprivate%2Ftianocore-code-review-poc%2F2020-May%2Fmsg00035.html&amp;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C1dcf1f8c03b544e5095408d7f5e2fd56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637248227586678640&amp;sdata=CgvZ8e%2B7L4nacvRE35KqEyC%2F1CjDYP6wI10qn%2BoX39Y%3D&amp;reserved=0
>>
>> # Tasks to Complete
>>
>> * Create edk2-codereview repository for evaluation of new code review process.
>> * Add GitHub IDs to Maintainers.txt in edk2-codereview repository
>> * Update BaseTools/Scripts/GetMaintainer.py to be compatible with GitHub IDs at
>>   the end of M: and R: statements
>> * Update webhook to use Rabbit MQ to manage requests and emails
>> * Determine if webhook requests must be serialized?  Current POC is serialized.
>> * Make sure webhook has error handling for all unexpected events/states.
>> * Add logging of all events and emails to webhook
> 
> The logging sounds very useful, thank you.
> 
> Whenever a log message relates to an email, please consider logging the
> message-id of that email, if possible.
> 
>> * Add admin interface to webhook
>> * Deploy webhook on a production server with 24/7 support
>>
>> # Ideas for Future Enhancements
>>
>> * Run PatchCheck.py before assigning maintainers/reviewers.
>> * Add a simple check that fails if a single patch spans more than one package.
> 
> Hmmm, good idea in general, but there have been valid exceptions to this
> rule.
> 
>> * Monitor comments for Reviewed-by, Acked-by, Tested-by, Series-Reviewed-by,
>>   Series-Acked-by, Series-Tested-by made by assigned maintainers/reviewers.
>>   Once all commits have required tags, auto update commit messages in the
>>   branch and wait for maintainer to set the `Push` label to run CI and auto
>>   merge if all CI checks pass.
> 
> Thank you for writing this up (and for implementing the webhook)!
> Laszlo
> 
> 
> 
> 
>