Hi Bret,

On 5/15/20 5:43 PM, Bret Barkelew via groups.io wrote:

I agree with some of your points, but I don’t believe that this calls for dependencies at all.

Which points are you disagreeing?

If a PR can pass CI with the changes, it’s functionally unordered.
And if a PR can’t, it has to wait until the PRs that can are in.
This also allows the group to focus on getting one thing done at a time.
I use rebase all the time and agree that it’s very good at precise history management. If a given PR requires that level of control, those tools will always be there.
But just as you say that the simple should not preclude the difficult, the difficult 5% should not needlessly complicated the simple 95%.
For what it’s worth, this is all posturing on my part. I intend – and, indeed, am eager to – follow the process that we’ve been helping Mike to set up.
- Bret
From: Laszlo Ersek<mailto:lersek@...>
Sent: Friday, May 15, 2020 2:08 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Bret Barkelew<mailto:Bret.Barkelew@...>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Kinney, Michael D<mailto:michael.d.kinney@...>
Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process
On 05/15/20 06:49, Bret Barkelew via groups.io wrote:

I would far prefer the approach of individual PRs for commits to
allow for the squash flexibility (and is the strategy I think I would
pursue with my PRs). For example, the VarPol PR would be broken up
into 9 PRs for each final commit, and we can get them in one by one.
Ideally, each one would be a small back and forth and then in. If it
had been done that way to begin with, it would be over in a week and
a half or so, rather than the multiple months that we’re now verging
on.

This differs extremely from how we've been working on edk2-devel (or
from how any git-based project works that I've ever been involved with).
And I think the above workflow is out of scope, for migrating the edk2
process to github.
Again, the structuring of a patch series is a primary trait. Iterating
only on individual patches does not allow for the reordering /
restructuring of the patch series (dropping patches, reordering patches,
inserting patches, moving hunks between patches).
It's common that the necessity to revise an earlier patch emerges while
reworking a later patch. For instance, the git-rebase(1) manual
dedicates a separate section to "splitting commits".
In the initial evaluation of "web forges", Phabricator was one of the
"contestants". Phabricator didn't support the "patch series" concept at
all, it only supported review requests for individual patches, and it
supported setting up dependencies between them. So, for example, a
27-patch series would require 27 submissions and 26 dependencies.
Lacking support for the patch series concept was an immediate deal
breaker with Phabricator.
The longest patch series I've ever submitted to edk2-devel had 58
patches. It was SMM enablement for OVMF. It went from v1 to v5 (v5 was
merged), and the patch count varied significantly:
v1: 58 patches (25 Jul 2015)
v2: 41 patches ( 9 Oct 2015)
v3: 52 patches (15 Oct 2015)
v4: 41 patches ( 3 Nov 2015)
v5: 33 patches (27 Nov 2015)
(The significant drop in the patch count was due to Mike Kinney open
sourcing and upstreaming the *real* PiSmmCpuDxeSmm driver (which was
huge work in its own right), allowing me to drop the Quark-originated
32-bit-only PiSmmCpuDxeSmm variant, from my series.)
The contribution process should make difficult things possible, even if
that complicates simple things somewhat. A process that makes simple
things simple and difficult things impossible is useless. This is what
the Instagram generation seems to be missing.
I don't know why the VariablePolicy work took months. I can see the
following threads on the list:
* [edk2-devel] [PATCH v1 0/9] Add the VariablePolicy feature
Fri, 10 Apr 2020 11:36:01 -0700
* [edk2-devel] [PATCH v2 00/12] Add the VariablePolicy feature
Mon, 11 May 2020 23:46:23 -0700
I have two sets of comments:
(1) It's difficult to tell in retrospect (because the series seem to
have been posted with somewhat problematic threading), but the delay
apparently came from multiple sources.
(1a) Review was slow and spotty.

IIUC it is easier for the "Instagram generation" to write a GitHub
plugin which ping an unmerged pullrequest for them, rather than tracking
their WiP and send a "ping" via an email client.

That reminds me of the Prophet tool:

Prophet: The first generate-and-validate tool that uses machine learning
techniques to learn useful knowledge from past human patches to
recognize correct patches. It is evaluated on the same benchmark as
GenProg and generate correct patches (i.e., equivalent to human patches)
for 18 out of 69 cases.

https://groups.csail.mit.edu/pac/patchgen/
https://en.wikipedia.org/wiki/Automatic_bug_fixing#C [8]

Use it as source, combined with a fuzzer that open GH pull-requests, and see if a patch get merged... /s

The v1 blurb received some comments in the first week after it was
posted. But the rest of the v1 series (the actual patches) received
feedback like this:
- v1 1/9: no feedback
- v1 2/9: 12 days after posting
- v1 3/9: 16 days after posting
- v1 4/9: no feedback
- v1 5/9: no feedback
- v1 6/9: no feedback
- v1 7/9: no feedback
- v1 8/9: no feedback
- v1 9/9: no feedback
(1b) There was also quite some time between the last response in the v1
thread (Apr 26th, as far as I can see), and the posting of the v2 series
(May 11th).
(1c) The v2 blurb got almost immediate, and numerous feedback (on the
day of posting, and the day after). Regarding the individual patches,
they didn't fare too well:
- v2 01/12: superficial comment on the day of posting from me (not a
designated MdeModulePkg review), on the day of posting; no
other feedback thus far
- v2 02/12: ditto
- v2 03/12: no feedback
- v2 04/12: superficial (coding style) comments on the day of posting
- v2 05/12: no feedback
- v2 06/12: no feedback
- v2 07/12: no feedback
- v2 08/12: no feedback
- v2 09/12: no feedback
- v2 10/12: no feedback
- v2 11/12: reasonably in-depth review from responsible co-maintainer
(yours truly), on the day of posting
- v2 12/12: no feedback
In total, I don't think the current process takes the blame for the
delay. If reviewers don't care (or have no time) now, that problem will
not change with the transition to github.com.
(2) The VariablePolicy series is actually a good example that patch
series restructuring is important.
(2a) The patch count went from 9 (in v1) to 12 (in v2).
(2b) And under v2, Liming still pointed out: "To keep each commit build
pass, the patch set should first add new library instance, then add the
library instance into each platform DSC, last update Variable driver to
consume new library instance."
Furthermore, I requested enabling the feature in ArmVirtPkg too, and
maybe (based on owner feedback) UefiPayloadPkg.
Thus, the v2->v3 update will most likely bring about both patch order
changes, and an increased patch count.
Thanks
Laszlo

Hi All,



I tend to agree with most of Laszlo's points. Specifically, that moving to pull requests will not fix the fact that maintainers are usually busy people and don't always give feedback in a punctual manner. Like Laszlo, I would also prefer that we do not squash patch series. My biggest reason for not squashing patch series is because when you put everything into a single commit, I have had to review commits with 500+ files changed. Opening git difftool on a commit like that is awful.



However, I would like to register my general endorsement for pull requests or some other web based system of code review… and I don’t have an Instagram account by the way :) Personally, I prefer Gerrit as I use it a lot with coreboot and other projects. But since we are using Github for hosting, pull requests are an easy switch and a logical choice. My main reason for being excited about pull requests mostly has to do with the amount of manual effort required to be a TianoCore maintainer right now. I have set up my email filter so that the mailing list is categorized like so:



[cid:image001.png@...]



Implementing the logic to parse the contents of emails to categorize them like this required me to define no less than 12 email filter rules in Microsoft Outlook, and I have to change my filtering logic every time I am added/removed from a Maintainers.txt file. I’m sure every other maintainer has spent a time separately implementing filtering logic like I have. This helps, but still for every thread, I have to go and check if one of the other maintainers has already reviewed/pushed that patch series yet, and if not review/push it. If I have ] feedback on a patch series, I have to categorize it as awaiting response from author and check up on it from time to time, sometimes I ping the author directly and remind them to send a new patch series. Implementing this state machine is a lot of manual work and it kind of feels like I’m a telephone operator in the 1950s. I greatly welcome automation here as I am sure it will increase the number of patch series I am able to review per hour.



Thanks,

Nate

On 05/19/20 09:21, Desimone, Nathaniel L wrote:

However, I would like to register my general endorsement for pull
requests or some other web based system of code review... and I don't
have an Instagram account by the way :) Personally, I prefer Gerrit as
I use it a lot with coreboot and other projects. But since we are
using Github for hosting, pull requests are an easy switch and a
logical choice. My main reason for being excited about pull requests
mostly has to do with the amount of manual effort required to be a
TianoCore maintainer right now.

My understanding is that, at this point, we're inevitably going to
migrate the contribution/review workflow to GitHub. I believe the switch
is going to happen once the email webhook has been deemed functional and
stable enough by the community.

Digression starts:

Implementing the logic to parse the contents of emails to categorize
them like this required me to define no less than 12 email filter
rules in Microsoft Outlook, and I have to change my filtering logic
every time I am added/removed from a Maintainers.txt file.

That seems strange. I have one rule per edk2-* list, for moving such
incoming email into the appropriate list folder. That's all.

While I read all the subject lines (skim all the threads) on edk2-devel,
generally, if you share reviewer or maintainer responsibilities for some
subsystem, then people posting patches for that subsystem are supposed
to CC you explicitly, in addition to messaging the list.

How you handle messages from then on may be a personal matter of course.
I simply tag ("star") such messages (patches / series pending my
review), and I revisit my "set of starred messages" every day (sometimes
multiple times per day).

I'm sure every other maintainer has spent a time separately
implementing filtering logic like I have. This helps, but still for
every thread, I have to go and check if one of the other maintainers
has already reviewed/pushed that patch series yet, and if not
review/push it.

Checking whether others have commented is near trivial if your MUA
supports a threaded view.

Checking whether a co-maintainer of yours has pushed a given series is
also simple if they diligently report the fact of merging on the list
(in the subject patch threads).

If I have feedback on a patch series, I have to categorize it as
awaiting response from author and check up on it from time to time,
sometimes I ping the author directly and remind them to send a new
patch series.

I think this is not your job, as a reviewer/maintainer. Once your review
is complete, or blocked on a question you need an answer to, the ball is
back in the contributor's court. They can answer, or post the next
version, whenever they see fit. Until then, the most they can expect of
you is answering any further questions they might have for understanding
your previous feedback better. You need not push contributors to
complete their contributions.

Implementing this state machine is a lot of manual work and it kind of
feels like I'm a telephone operator in the 1950s. I greatly welcome
automation here as I am sure it will increase the number of patch
series I am able to review per hour.

"State machine" is a very good analogy! Personally, I don't find it
tiresome. Yes, it's important to recognize the events (= new emails)
that trigger transitions between states. (For example: when I complete a
review, when I get a new version of a series or a brand new series, when
I get asked a question.) Once I recognize those events correctly, I just
diligently massage said tags ("stars").

And I keep iterating over my set of "starred" messages; I do actual work
(e.g., reviews) in "bottom halves"; detached from new emails.

I don't find this a burden as I have to manage my "real life" with task
lists anyway. Without them, my real life would collapse in a week; so
it's nothing unusual for me. (And no, I don't allow shady cloud-based
automatisms to manage my life for me; I value my privacy way above my
comfort.)

Thanks!
Laszlo

Nate/Laszlo,

Regarding a squash merge workflow. I agree it can be abused and we all have seen terrible examples. But a patch series that contains 500+ file changes isn't really much better. Just because it is broken into multiple commits doesn't mean it is the right set of commits.

Anyway a squash merge workflow works amazingly well with and is optimized for a web based review and PR processes. It allows a user to respond to changes, fix issues, learn thru the PR process, all while keeping complete track of the progression. Then once all "status" checks and reviews are complete, it is squashed into a neat commit for mainline, containing only the relevant data in the message.

So, the ask is that we don't exclude squash merge workflows. Those reviewing the PR can decide what is appropriate for the PR content submitted. Just as you would request changes to the contents (or ordering) of a commit in a series, if the reviewers don't agree that the PR contents should be in a single commit then obviously it shouldn't be squashed to one.

Contributions like spelling fixes, typos, minor bug fixes, documentation additions/fixes, etc all are great examples of PRs that can easily leverage squash merges and this workflow significantly lowers the burden of the contribution and review process. This workflow is also are much easier for casual or first time contributors.

I don't exactly know how we would enable this but I assume we could leverage tags or make it clear in the PR description. First step is to get alignment that a squash merge workflow, while not appropriate for all contributions, is not something to be excluded.

Thanks
Sean

On 5/19/20 01:40, Laszlo Ersek wrote:

That seems strange. I have one rule per edk2-* list, for moving such incoming
email into the appropriate list folder. That's all.

While I read all the subject lines (skim all the threads) on edk2-devel,
generally, if you share reviewer or maintainer responsibilities for some
subsystem, then people posting patches for that subsystem are supposed to
CC you explicitly, in addition to messaging the list.

I tend to make the assumption that people do not CC me on the patches that they are supposed to CC me on. So I set up my filtering rules to do a deep inspection of the message contents to see if it touches a package that I maintain.

Checking whether others have commented is near trivial if your MUA
supports a threaded view.

Checking whether a co-maintainer of yours has pushed a given series is also
simple if they diligently report the fact of merging on the list (in the subject
patch threads).

Yes, checking for comments is trivial. However, my fellow co-maintainers are not very diligent on sending push notifications. So when I see comments from one of my fellow co-maintainers I immediately ask myself the question: "Did they already push this, and does it make sense for me to spend time reviewing this patch series?" Answering that question involves a git pull and a review of history in gitk to see what has been done already.

I think this is not your job, as a reviewer/maintainer. Once your review is
complete, or blocked on a question you need an answer to, the ball is back in
the contributor's court. They can answer, or post the next version, whenever
they see fit. Until then, the most they can expect of you is answering any
further questions they might have for understanding your previous feedback
better. You need not push contributors to complete their contributions.

I think my experience is colored somewhat here. I'd say more than half the time, the contributor is another Intel employee. Often times, they are contributing code changes that I asked them to implement. :)

"State machine" is a very good analogy! Personally, I don't find it tiresome.
Yes, it's important to recognize the events (= new emails) that trigger
transitions between states. (For example: when I complete a review, when I
get a new version of a series or a brand new series, when I get asked a
question.) Once I recognize those events correctly, I just diligently massage
said tags ("stars").

And I keep iterating over my set of "starred" messages; I do actual work
(e.g., reviews) in "bottom halves"; detached from new emails.

I don't find this a burden as I have to manage my "real life" with task lists
anyway. Without them, my real life would collapse in a week; so it's nothing
unusual for me. (And no, I don't allow shady cloud-based automatisms to
manage my life for me; I value my privacy way above my
comfort.)

Agreed that I also keep my personal task lists in a paper notebook and manage my real life list manually. However, my real life list is much smaller (since I have most of the context in my head already)... and its private. Everything I do on this mailing list is public anyway, so having some centralized service keep track of state transitions doesn't bother me. The "bottom half" of that state transition is going to generate a public email from my address, so it's not like the current state of the state machine that I'm running in my head is private.

Thanks,
Nate

Thanks!
Laszlo

Hi Sean,

My recent spelling fix patch series is a good example of why this is a bad idea actually:

https://edk2.groups.io/g/devel/message/59779
https://edk2.groups.io/g/devel/message/59780
https://edk2.groups.io/g/devel/message/59781
https://edk2.groups.io/g/devel/message/59782
https://edk2.groups.io/g/devel/message/59783
https://edk2.groups.io/g/devel/message/59784
https://edk2.groups.io/g/devel/message/59785

Notice that I split along package boundaries, because the maintainers for each package is a different set of people. If my patch series was squashed at merge time... how do I know who reviewed what? If the commit set is not correct.. I tend to say so in my feedback :). The only sane way to squash this series would be to have a human re-write all the commit messages, which I am against.

Generally those that prefer an easily bisectable history have such preference mostly due to the usage of validators that immediately resort bisecting as a method to root cause an issue since they tend to not understand the code very well. Edk2 already has 12 years of non-bisectable history, so this method is going to be ineffective anyway.

With regard to sending squashed commits, I understand that those who are new may have difficulty sending a properly formatted patch series, but frankly attempting to shield them from having to learn I am strongly against. I suggest that Microsoft invest in its human capital similar to how Intel does. If you cannot figure out how to send a properly formatted patch series... then do your work on the internal codebase (or perhaps MU.) Within the Intel, having the skillset to contribute to TianoCore is considered a mark of prestige, and thus needs to be earned.

TLDR, I will reject squashed commits on any packages that I maintain.

Thanks,
Nate

Nate, I believe you missed Sean’s point.

Each one of those packages should have been a separate PR.
Ergo, no information would have been lost in the squash.

Also, it’s not so much that we *can’t* learn. It’s that we choose not to. Around here, it’s a mark of prestige to not open doors with your face if it seems like there’s a better way. Makes it easier to focus on the work.

- Bret

From: Nate DeSimone via groups.io<mailto:nathaniel.l.desimone@...>
Sent: Tuesday, May 19, 2020 11:02 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@...<mailto:spbrogan@...>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@...<mailto:lersek@...>; Bret Barkelew<mailto:Bret.Barkelew@...>; Kinney, Michael D<mailto:michael.d.kinney@...>
Subject: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Hi Sean,

My recent spelling fix patch series is a good example of why this is a bad idea actually:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59779&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=fVz16E37%2BwW5pSgRxI45K7nWPDlIoS0HuI8UCGmEwjY%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59780&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=4q0lC1BSlSoQ3p0HGWwlph09HTjgJRo4nTO2Qx59%2Fjc%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59781&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=XQVSwPMXdpDJXj9nkuvq2fenwhNt6HGGZXsJwH5Bu8E%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59782&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=kCULGBc6%2Bifcn3cnPTV1odHI1ZUxuWQePN3POKKS3SM%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59783&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=SCOhUMdNXHIymGLaw9z3JTh%2Fe2BfaJaAyEC99EkG%2Fvg%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59784&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=epET6Wk30bIHQCvEDFLkeHEfmm9tzlxRrJ%2FQAuEfQFs%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59785&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=N8T7HjerJVvyGg94yMWjLm%2Fw7WDdXOdby1JpOYlPeVc%3D&amp;reserved=0

Notice that I split along package boundaries, because the maintainers for each package is a different set of people. If my patch series was squashed at merge time... how do I know who reviewed what? If the commit set is not correct.. I tend to say so in my feedback :). The only sane way to squash this series would be to have a human re-write all the commit messages, which I am against.

Generally those that prefer an easily bisectable history have such preference mostly due to the usage of validators that immediately resort bisecting as a method to root cause an issue since they tend to not understand the code very well. Edk2 already has 12 years of non-bisectable history, so this method is going to be ineffective anyway.

With regard to sending squashed commits, I understand that those who are new may have difficulty sending a properly formatted patch series, but frankly attempting to shield them from having to learn I am strongly against. I suggest that Microsoft invest in its human capital similar to how Intel does. If you cannot figure out how to send a properly formatted patch series... then do your work on the internal codebase (or perhaps MU.) Within the Intel, having the skillset to contribute to TianoCore is considered a mark of prestige, and thus needs to be earned.

TLDR, I will reject squashed commits on any packages that I maintain.

Thanks,
Nate

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sean
Sent: Tuesday, May 19, 2020 9:54 AM
To: rfc@edk2.groups.io; Desimone, Nathaniel L
<nathaniel.l.desimone@...>; lersek@...;
bret.barkelew@...; devel@edk2.groups.io; Kinney, Michael D
<michael.d.kinney@...>
Subject: Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review
Process

Nate/Laszlo,

Regarding a squash merge workflow. I agree it can be abused and we all
have seen terrible examples. But a patch series that contains 500+ file
changes isn't really much better. Just because it is broken into multiple
commits doesn't mean it is the right set of commits.

Anyway a squash merge workflow works amazingly well with and is
optimized for a web based review and PR processes. It allows a user to
respond to changes, fix issues, learn thru the PR process, all while keeping
complete track of the progression. Then once all "status"
checks and reviews are complete, it is squashed into a neat commit for
mainline, containing only the relevant data in the message.

So, the ask is that we don't exclude squash merge workflows. Those
reviewing the PR can decide what is appropriate for the PR content
submitted. Just as you would request changes to the contents (or
ordering) of a commit in a series, if the reviewers don't agree that the PR
contents should be in a single commit then obviously it shouldn't be
squashed to one.

Contributions like spelling fixes, typos, minor bug fixes, documentation
additions/fixes, etc all are great examples of PRs that can easily leverage
squash merges and this workflow significantly lowers the burden of the
contribution and review process. This workflow is also are much easier for
casual or first time contributors.

I don't exactly know how we would enable this but I assume we could
leverage tags or make it clear in the PR description. First step is to get
alignment that a squash merge workflow, while not appropriate for all
contributions, is not something to be excluded.

Thanks
Sean



On 5/19/2020 12:21 AM, Nate DeSimone wrote:

Hi All,



I tend to agree with most of Laszlo's points. Specifically, that moving to pull

requests will not fix the fact that maintainers are usually busy people and
don't always give feedback in a punctual manner. Like Laszlo, I would also
prefer that we do not squash patch series. My biggest reason for not
squashing patch series is because when you put everything into a single
commit, I have had to review commits with 500+ files changed. Opening git
difftool on a commit like that is awful.

However, I would like to register my general endorsement for pull requests

or some other web based system of code review… and I don’t have an
Instagram account by the way :) Personally, I prefer Gerrit as I use it a lot with
coreboot and other projects. But since we are using Github for hosting, pull
requests are an easy switch and a logical choice. My main reason for being
excited about pull requests mostly has to do with the amount of manual
effort required to be a TianoCore maintainer right now. I have set up my
email filter so that the mailing list is categorized like so:

[cid:image001.png@...]



Implementing the logic to parse the contents of emails to categorize them

like this required me to define no less than 12 email filter rules in Microsoft
Outlook, and I have to change my filtering logic every time I am
added/removed from a Maintainers.txt file. I’m sure every other maintainer
has spent a time separately implementing filtering logic like I have. This helps,
but still for every thread, I have to go and check if one of the other
maintainers has already reviewed/pushed that patch series yet, and if not
review/push it. If I have ] feedback on a patch series, I have to categorize it
as awaiting response from author and check up on it from time to time,
sometimes I ping the author directly and remind them to send a new patch
series. Implementing this state machine is a lot of manual work and it kind of
feels like I’m a telephone operator in the 1950s. I greatly welcome
automation here as I am sure it will increase the number of patch series I am
able to review per hour.

Thanks,

Nate



-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Laszlo
Ersek
Sent: Friday, May 15, 2020 2:08 AM
To: rfc@edk2.groups.io; bret.barkelew@...;
devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@...>
Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull
Request based Code Review Process



On 05/15/20 06:49, Bret Barkelew via groups.io wrote:

I would far prefer the approach of individual PRs for commits to
allow

for the squash flexibility (and is the strategy I think I would
pursue

with my PRs). For example, the VarPol PR would be broken up into 9
PRs

for each final commit, and we can get them in one by one.

Ideally, each one would be a small back and forth and then in. If it

had been done that way to begin with, it would be over in a week and
a

half or so, rather than the multiple months that we’re now verging

on.

This differs extremely from how we've been working on edk2-devel (or

from how any git-based project works that I've ever been involved with).

And I think the above workflow is out of scope, for migrating the edk2

process to github.

Again, the structuring of a patch series is a primary trait. Iterating only on

individual patches does not allow for the reordering / restructuring of the
patch series (dropping patches, reordering patches, inserting patches,
moving hunks between patches).

It's common that the necessity to revise an earlier patch emerges while

reworking a later patch. For instance, the git-rebase(1) manual dedicates a
separate section to "splitting commits".

In the initial evaluation of "web forges", Phabricator was one of the

"contestants". Phabricator didn't support the "patch series" concept at all, it
only supported review requests for individual patches, and it supported
setting up dependencies between them. So, for example, a 27-patch series
would require 27 submissions and 26 dependencies.

Lacking support for the patch series concept was an immediate deal

breaker with Phabricator.

The longest patch series I've ever submitted to edk2-devel had 58 patches.

It was SMM enablement for OVMF. It went from v1 to v5 (v5 was merged),
and the patch count varied significantly:

v1: 58 patches (25 Jul 2015)

v2: 41 patches ( 9 Oct 2015)

v3: 52 patches (15 Oct 2015)

v4: 41 patches ( 3 Nov 2015)

v5: 33 patches (27 Nov 2015)



(The significant drop in the patch count was due to Mike Kinney open
sourcing and upstreaming the *real* PiSmmCpuDxeSmm driver (which was
huge work in its own right), allowing me to drop the Quark-originated
32-bit-only PiSmmCpuDxeSmm variant, from my series.)



The contribution process should make difficult things possible, even if that

complicates simple things somewhat. A process that makes simple things
simple and difficult things impossible is useless. This is what the Instagram
generation seems to be missing.

I don't know why the VariablePolicy work took months. I can see the

following threads on the list:

* [edk2-devel] [PATCH v1 0/9] Add the VariablePolicy feature

Fri, 10 Apr 2020 11:36:01 -0700



* [edk2-devel] [PATCH v2 00/12] Add the VariablePolicy feature

Mon, 11 May 2020 23:46:23 -0700



I have two sets of comments:



(1) It's difficult to tell in retrospect (because the series seem to have been

posted with somewhat problematic threading), but the delay apparently
came from multiple sources.

(1a) Review was slow and spotty.



The v1 blurb received some comments in the first week after it was posted.

But the rest of the v1 series (the actual patches) received feedback like this:

- v1 1/9: no feedback

- v1 2/9: 12 days after posting

- v1 3/9: 16 days after posting

- v1 4/9: no feedback

- v1 5/9: no feedback

- v1 6/9: no feedback

- v1 7/9: no feedback

- v1 8/9: no feedback

- v1 9/9: no feedback



(1b) There was also quite some time between the last response in the v1

thread (Apr 26th, as far as I can see), and the posting of the v2 series (May
11th).

(1c) The v2 blurb got almost immediate, and numerous feedback (on the

day of posting, and the day after). Regarding the individual patches, they
didn't fare too well:

- v2 01/12: superficial comment on the day of posting from me (not a

designated MdeModulePkg review), on the day of posting;
no

other feedback thus far

- v2 02/12: ditto

- v2 03/12: no feedback

- v2 04/12: superficial (coding style) comments on the day of posting

- v2 05/12: no feedback

- v2 06/12: no feedback

- v2 07/12: no feedback

- v2 08/12: no feedback

- v2 09/12: no feedback

- v2 10/12: no feedback

- v2 11/12: reasonably in-depth review from responsible co-maintainer

(yours truly), on the day of posting

- v2 12/12: no feedback



In total, I don't think the current process takes the blame for the delay. If

reviewers don't care (or have no time) now, that problem will not change
with the transition to github.com.

(2) The VariablePolicy series is actually a good example that patch series

restructuring is important.

(2a) The patch count went from 9 (in v1) to 12 (in v2).



(2b) And under v2, Liming still pointed out: "To keep each commit build

pass, the patch set should first add new library instance, then add the library
instance into each platform DSC, last update Variable driver to consume new
library instance."

Furthermore, I requested enabling the feature in ArmVirtPkg too, and

maybe (based on owner feedback) UefiPayloadPkg.

Thus, the v2->v3 update will most likely bring about both patch order

changes, and an increased patch count.

Thanks

Laszlo

Hi Bret,

I believe you missed my point. I don’t want my patch series to be merged piece by piece; I want it merged all at once, in the order that I specified.

I tend to agree with Laszlo that you are choosing not to learn how to use Git properly. Commit early, commit often, perfect later, publish once is the Git best practice. You should not hide the sausage making, which is exactly what you are proposing. I find it unfortunate that you consider refusing to learn GIt best practices a mark of prestige.

Thanks,
Nate

From: <devel@edk2.groups.io> on behalf of "Bret Barkelew via groups.io" <bret.barkelew@...>
Reply-To: "devel@edk2.groups.io" <devel@edk2.groups.io>, "bret.barkelew@..." <bret.barkelew@...>
Date: Tuesday, May 19, 2020 at 12:35 PM
To: "devel@edk2.groups.io" <devel@edk2.groups.io>, "Desimone, Nathaniel L" <nathaniel.l.desimone@...>, "spbrogan@..." <spbrogan@...>, "rfc@edk2.groups.io" <rfc@edk2.groups.io>, "lersek@..." <lersek@...>, "Kinney, Michael D" <michael.d.kinney@...>
Subject: Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Nate, I believe you missed Sean’s point.

Each one of those packages should have been a separate PR.
Ergo, no information would have been lost in the squash.

Also, it’s not so much that we *can’t* learn. It’s that we choose not to. Around here, it’s a mark of prestige to not open doors with your face if it seems like there’s a better way. Makes it easier to focus on the work.

- Bret

From: Nate DeSimone via groups.io<mailto:nathaniel.l.desimone@...>
Sent: Tuesday, May 19, 2020 11:02 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@...<mailto:spbrogan@...>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@...<mailto:lersek@...>; Bret Barkelew<mailto:Bret.Barkelew@...>; Kinney, Michael D<mailto:michael.d.kinney@...>
Subject: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Hi Sean,

My recent spelling fix patch series is a good example of why this is a bad idea actually:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59779&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=fVz16E37%2BwW5pSgRxI45K7nWPDlIoS0HuI8UCGmEwjY%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59780&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=4q0lC1BSlSoQ3p0HGWwlph09HTjgJRo4nTO2Qx59%2Fjc%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59781&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=XQVSwPMXdpDJXj9nkuvq2fenwhNt6HGGZXsJwH5Bu8E%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59782&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=kCULGBc6%2Bifcn3cnPTV1odHI1ZUxuWQePN3POKKS3SM%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59783&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=SCOhUMdNXHIymGLaw9z3JTh%2Fe2BfaJaAyEC99EkG%2Fvg%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59784&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=epET6Wk30bIHQCvEDFLkeHEfmm9tzlxRrJ%2FQAuEfQFs%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59785&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=N8T7HjerJVvyGg94yMWjLm%2Fw7WDdXOdby1JpOYlPeVc%3D&amp;reserved=0

Notice that I split along package boundaries, because the maintainers for each package is a different set of people. If my patch series was squashed at merge time... how do I know who reviewed what? If the commit set is not correct.. I tend to say so in my feedback :). The only sane way to squash this series would be to have a human re-write all the commit messages, which I am against.

Generally those that prefer an easily bisectable history have such preference mostly due to the usage of validators that immediately resort bisecting as a method to root cause an issue since they tend to not understand the code very well. Edk2 already has 12 years of non-bisectable history, so this method is going to be ineffective anyway.

With regard to sending squashed commits, I understand that those who are new may have difficulty sending a properly formatted patch series, but frankly attempting to shield them from having to learn I am strongly against. I suggest that Microsoft invest in its human capital similar to how Intel does. If you cannot figure out how to send a properly formatted patch series... then do your work on the internal codebase (or perhaps MU.) Within the Intel, having the skillset to contribute to TianoCore is considered a mark of prestige, and thus needs to be earned.

TLDR, I will reject squashed commits on any packages that I maintain.

Thanks,
Nate

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sean
Sent: Tuesday, May 19, 2020 9:54 AM
To: rfc@edk2.groups.io; Desimone, Nathaniel L
<nathaniel.l.desimone@...>; lersek@...;
bret.barkelew@...; devel@edk2.groups.io; Kinney, Michael D
<michael.d.kinney@...>
Subject: Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review
Process

Nate/Laszlo,

Regarding a squash merge workflow. I agree it can be abused and we all
have seen terrible examples. But a patch series that contains 500+ file
changes isn't really much better. Just because it is broken into multiple
commits doesn't mean it is the right set of commits.

Anyway a squash merge workflow works amazingly well with and is
optimized for a web based review and PR processes. It allows a user to
respond to changes, fix issues, learn thru the PR process, all while keeping
complete track of the progression. Then once all "status"
checks and reviews are complete, it is squashed into a neat commit for
mainline, containing only the relevant data in the message.

So, the ask is that we don't exclude squash merge workflows. Those
reviewing the PR can decide what is appropriate for the PR content
submitted. Just as you would request changes to the contents (or
ordering) of a commit in a series, if the reviewers don't agree that the PR
contents should be in a single commit then obviously it shouldn't be
squashed to one.

Contributions like spelling fixes, typos, minor bug fixes, documentation
additions/fixes, etc all are great examples of PRs that can easily leverage
squash merges and this workflow significantly lowers the burden of the
contribution and review process. This workflow is also are much easier for
casual or first time contributors.

I don't exactly know how we would enable this but I assume we could
leverage tags or make it clear in the PR description. First step is to get
alignment that a squash merge workflow, while not appropriate for all
contributions, is not something to be excluded.

Thanks
Sean



On 5/19/2020 12:21 AM, Nate DeSimone wrote:

Hi All,



I tend to agree with most of Laszlo's points. Specifically, that moving to pull

requests will not fix the fact that maintainers are usually busy people and
don't always give feedback in a punctual manner. Like Laszlo, I would also
prefer that we do not squash patch series. My biggest reason for not
squashing patch series is because when you put everything into a single
commit, I have had to review commits with 500+ files changed. Opening git
difftool on a commit like that is awful.

However, I would like to register my general endorsement for pull requests

or some other web based system of code review… and I don’t have an
Instagram account by the way :) Personally, I prefer Gerrit as I use it a lot with
coreboot and other projects. But since we are using Github for hosting, pull
requests are an easy switch and a logical choice. My main reason for being
excited about pull requests mostly has to do with the amount of manual
effort required to be a TianoCore maintainer right now. I have set up my
email filter so that the mailing list is categorized like so:

[cid:image001.png@...]



Implementing the logic to parse the contents of emails to categorize them

like this required me to define no less than 12 email filter rules in Microsoft
Outlook, and I have to change my filtering logic every time I am
added/removed from a Maintainers.txt file. I’m sure every other maintainer
has spent a time separately implementing filtering logic like I have. This helps,
but still for every thread, I have to go and check if one of the other
maintainers has already reviewed/pushed that patch series yet, and if not
review/push it. If I have ] feedback on a patch series, I have to categorize it
as awaiting response from author and check up on it from time to time,
sometimes I ping the author directly and remind them to send a new patch
series. Implementing this state machine is a lot of manual work and it kind of
feels like I’m a telephone operator in the 1950s. I greatly welcome
automation here as I am sure it will increase the number of patch series I am
able to review per hour.

Thanks,

Nate



-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Laszlo
Ersek
Sent: Friday, May 15, 2020 2:08 AM
To: rfc@edk2.groups.io; bret.barkelew@...;
devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@...>
Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull
Request based Code Review Process



On 05/15/20 06:49, Bret Barkelew via groups.io wrote:

I would far prefer the approach of individual PRs for commits to
allow

for the squash flexibility (and is the strategy I think I would
pursue

with my PRs). For example, the VarPol PR would be broken up into 9
PRs

for each final commit, and we can get them in one by one.

Ideally, each one would be a small back and forth and then in. If it

had been done that way to begin with, it would be over in a week and
a

half or so, rather than the multiple months that we’re now verging

on.

This differs extremely from how we've been working on edk2-devel (or

from how any git-based project works that I've ever been involved with).

And I think the above workflow is out of scope, for migrating the edk2

process to github.

Again, the structuring of a patch series is a primary trait. Iterating only on

individual patches does not allow for the reordering / restructuring of the
patch series (dropping patches, reordering patches, inserting patches,
moving hunks between patches).

It's common that the necessity to revise an earlier patch emerges while

reworking a later patch. For instance, the git-rebase(1) manual dedicates a
separate section to "splitting commits".

In the initial evaluation of "web forges", Phabricator was one of the

"contestants". Phabricator didn't support the "patch series" concept at all, it
only supported review requests for individual patches, and it supported
setting up dependencies between them. So, for example, a 27-patch series
would require 27 submissions and 26 dependencies.

Lacking support for the patch series concept was an immediate deal

breaker with Phabricator.

The longest patch series I've ever submitted to edk2-devel had 58 patches.

It was SMM enablement for OVMF. It went from v1 to v5 (v5 was merged),
and the patch count varied significantly:

v1: 58 patches (25 Jul 2015)

v2: 41 patches ( 9 Oct 2015)

v3: 52 patches (15 Oct 2015)

v4: 41 patches ( 3 Nov 2015)

v5: 33 patches (27 Nov 2015)



(The significant drop in the patch count was due to Mike Kinney open
sourcing and upstreaming the *real* PiSmmCpuDxeSmm driver (which was
huge work in its own right), allowing me to drop the Quark-originated
32-bit-only PiSmmCpuDxeSmm variant, from my series.)



The contribution process should make difficult things possible, even if that

complicates simple things somewhat. A process that makes simple things
simple and difficult things impossible is useless. This is what the Instagram
generation seems to be missing.

I don't know why the VariablePolicy work took months. I can see the

following threads on the list:

* [edk2-devel] [PATCH v1 0/9] Add the VariablePolicy feature

Fri, 10 Apr 2020 11:36:01 -0700



* [edk2-devel] [PATCH v2 00/12] Add the VariablePolicy feature

Mon, 11 May 2020 23:46:23 -0700



I have two sets of comments:



(1) It's difficult to tell in retrospect (because the series seem to have been

posted with somewhat problematic threading), but the delay apparently
came from multiple sources.

(1a) Review was slow and spotty.



The v1 blurb received some comments in the first week after it was posted.

But the rest of the v1 series (the actual patches) received feedback like this:

- v1 1/9: no feedback

- v1 2/9: 12 days after posting

- v1 3/9: 16 days after posting

- v1 4/9: no feedback

- v1 5/9: no feedback

- v1 6/9: no feedback

- v1 7/9: no feedback

- v1 8/9: no feedback

- v1 9/9: no feedback



(1b) There was also quite some time between the last response in the v1

thread (Apr 26th, as far as I can see), and the posting of the v2 series (May
11th).

(1c) The v2 blurb got almost immediate, and numerous feedback (on the

day of posting, and the day after). Regarding the individual patches, they
didn't fare too well:

- v2 01/12: superficial comment on the day of posting from me (not a

designated MdeModulePkg review), on the day of posting;
no

other feedback thus far

- v2 02/12: ditto

- v2 03/12: no feedback

- v2 04/12: superficial (coding style) comments on the day of posting

- v2 05/12: no feedback

- v2 06/12: no feedback

- v2 07/12: no feedback

- v2 08/12: no feedback

- v2 09/12: no feedback

- v2 10/12: no feedback

- v2 11/12: reasonably in-depth review from responsible co-maintainer

(yours truly), on the day of posting

- v2 12/12: no feedback



In total, I don't think the current process takes the blame for the delay. If

reviewers don't care (or have no time) now, that problem will not change
with the transition to github.com.

(2) The VariablePolicy series is actually a good example that patch series

restructuring is important.

(2a) The patch count went from 9 (in v1) to 12 (in v2).



(2b) And under v2, Liming still pointed out: "To keep each commit build

pass, the patch set should first add new library instance, then add the library
instance into each platform DSC, last update Variable driver to consume new
library instance."

Furthermore, I requested enabling the feature in ArmVirtPkg too, and

maybe (based on owner feedback) UefiPayloadPkg.

Thus, the v2->v3 update will most likely bring about both patch order

changes, and an increased patch count.

Thanks

Laszlo

I will honor Mike Kinney’s efforts with my vote of confidence.
I think we’re headed in the right direction, even with some of the things that I disagree with.

In my history with TianoCore, I have learned to not be so quick to say “this is fucking stupid”. Every time I’ve done that, I’ve later discovered the reasons behind it, and even come to the conclusion that the designers were quite clever.

That said, I want to contribute. And I won’t with the current system. I hope to be able to with the future system.

- Bret

From: Desimone, Nathaniel L<mailto:nathaniel.l.desimone@...>
Sent: Tuesday, May 19, 2020 12:59 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Bret Barkelew<mailto:Bret.Barkelew@...>; spbrogan@...<mailto:spbrogan@...>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@...<mailto:lersek@...>; Kinney, Michael D<mailto:michael.d.kinney@...>
Subject: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Hi Bret,

I believe you missed my point. I don’t want my patch series to be merged piece by piece; I want it merged all at once, in the order that I specified.

I tend to agree with Laszlo that you are choosing not to learn how to use Git properly. Commit early, commit often, perfect later, publish once is the Git best practice. You should not hide the sausage making, which is exactly what you are proposing. I find it unfortunate that you consider refusing to learn GIt best practices a mark of prestige.

Thanks,
Nate

From: <devel@edk2.groups.io> on behalf of "Bret Barkelew via groups.io" <bret.barkelew@...>
Reply-To: "devel@edk2.groups.io" <devel@edk2.groups.io>, "bret.barkelew@..." <bret.barkelew@...>
Date: Tuesday, May 19, 2020 at 12:35 PM
To: "devel@edk2.groups.io" <devel@edk2.groups.io>, "Desimone, Nathaniel L" <nathaniel.l.desimone@...>, "spbrogan@..." <spbrogan@...>, "rfc@edk2.groups.io" <rfc@edk2.groups.io>, "lersek@..." <lersek@...>, "Kinney, Michael D" <michael.d.kinney@...>
Subject: Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Nate, I believe you missed Sean’s point.

Each one of those packages should have been a separate PR.
Ergo, no information would have been lost in the squash.

Also, it’s not so much that we *can’t* learn. It’s that we choose not to. Around here, it’s a mark of prestige to not open doors with your face if it seems like there’s a better way. Makes it easier to focus on the work.

- Bret

From: Nate DeSimone via groups.io<mailto:nathaniel.l.desimone@...>
Sent: Tuesday, May 19, 2020 11:02 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@...<mailto:spbrogan@...>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@...<mailto:lersek@...>; Bret Barkelew<mailto:Bret.Barkelew@...>; Kinney, Michael D<mailto:michael.d.kinney@...>
Subject: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Hi Sean,

My recent spelling fix patch series is a good example of why this is a bad idea actually:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59779&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=fVz16E37%2BwW5pSgRxI45K7nWPDlIoS0HuI8UCGmEwjY%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59779&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cbf6d5aed67374c95ca3508d7fc2f20ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255151662145479&sdata=m66IViN3G%2BbJpBwolRXf8d3BpWQeRXs495WYxnsD85M%3D&reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59780&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=4q0lC1BSlSoQ3p0HGWwlph09HTjgJRo4nTO2Qx59%2Fjc%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59780&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cbf6d5aed67374c95ca3508d7fc2f20ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255151662155477&sdata=VuYPqwcmYTrbiYdo%2B8K5irX8k6rgMgEoC2fY8eAocWA%3D&reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59781&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=XQVSwPMXdpDJXj9nkuvq2fenwhNt6HGGZXsJwH5Bu8E%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59781&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cbf6d5aed67374c95ca3508d7fc2f20ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255151662165472&sdata=lMrhfWKBWKGkjNnXJJy7%2BisrugTi0J%2FUkmtnj7Vxb7Q%3D&reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59782&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=kCULGBc6%2Bifcn3cnPTV1odHI1ZUxuWQePN3POKKS3SM%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59782&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cbf6d5aed67374c95ca3508d7fc2f20ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255151662165472&sdata=rltVYSQcSLG2sGP4d2awDIuWV11nYQcdxvqyPxDM4XE%3D&reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59783&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=SCOhUMdNXHIymGLaw9z3JTh%2Fe2BfaJaAyEC99EkG%2Fvg%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59783&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cbf6d5aed67374c95ca3508d7fc2f20ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255151662175469&sdata=b0J%2BL4nddt3g%2FmidZO61tlkgVqrRsufOUHGjRqh1CJM%3D&reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59784&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=epET6Wk30bIHQCvEDFLkeHEfmm9tzlxRrJ%2FQAuEfQFs%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59784&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cbf6d5aed67374c95ca3508d7fc2f20ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255151662185463&sdata=zhHUUmckRdY45oYIPodqP9r3Sh4Q4t%2FZYRLULOiAERs%3D&reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59785&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=N8T7HjerJVvyGg94yMWjLm%2Fw7WDdXOdby1JpOYlPeVc%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59785&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cbf6d5aed67374c95ca3508d7fc2f20ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255151662185463&sdata=MNUfWJhjb1UfPFciUJ2dcu9uWQwUNkS3PJO%2BeMkFVxA%3D&reserved=0>

Notice that I split along package boundaries, because the maintainers for each package is a different set of people. If my patch series was squashed at merge time... how do I know who reviewed what? If the commit set is not correct.. I tend to say so in my feedback :). The only sane way to squash this series would be to have a human re-write all the commit messages, which I am against.

Generally those that prefer an easily bisectable history have such preference mostly due to the usage of validators that immediately resort bisecting as a method to root cause an issue since they tend to not understand the code very well. Edk2 already has 12 years of non-bisectable history, so this method is going to be ineffective anyway.

With regard to sending squashed commits, I understand that those who are new may have difficulty sending a properly formatted patch series, but frankly attempting to shield them from having to learn I am strongly against. I suggest that Microsoft invest in its human capital similar to how Intel does. If you cannot figure out how to send a properly formatted patch series... then do your work on the internal codebase (or perhaps MU.) Within the Intel, having the skillset to contribute to TianoCore is considered a mark of prestige, and thus needs to be earned.

TLDR, I will reject squashed commits on any packages that I maintain.

Thanks,
Nate

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sean
Sent: Tuesday, May 19, 2020 9:54 AM
To: rfc@edk2.groups.io; Desimone, Nathaniel L
<nathaniel.l.desimone@...>; lersek@...;
bret.barkelew@...; devel@edk2.groups.io; Kinney, Michael D
<michael.d.kinney@...>
Subject: Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review
Process

Nate/Laszlo,

Regarding a squash merge workflow. I agree it can be abused and we all
have seen terrible examples. But a patch series that contains 500+ file
changes isn't really much better. Just because it is broken into multiple
commits doesn't mean it is the right set of commits.

Anyway a squash merge workflow works amazingly well with and is
optimized for a web based review and PR processes. It allows a user to
respond to changes, fix issues, learn thru the PR process, all while keeping
complete track of the progression. Then once all "status"
checks and reviews are complete, it is squashed into a neat commit for
mainline, containing only the relevant data in the message.

So, the ask is that we don't exclude squash merge workflows. Those
reviewing the PR can decide what is appropriate for the PR content
submitted. Just as you would request changes to the contents (or
ordering) of a commit in a series, if the reviewers don't agree that the PR
contents should be in a single commit then obviously it shouldn't be
squashed to one.

Contributions like spelling fixes, typos, minor bug fixes, documentation
additions/fixes, etc all are great examples of PRs that can easily leverage
squash merges and this workflow significantly lowers the burden of the
contribution and review process. This workflow is also are much easier for
casual or first time contributors.

I don't exactly know how we would enable this but I assume we could
leverage tags or make it clear in the PR description. First step is to get
alignment that a squash merge workflow, while not appropriate for all
contributions, is not something to be excluded.

Thanks
Sean



On 5/19/2020 12:21 AM, Nate DeSimone wrote:

Hi All,



I tend to agree with most of Laszlo's points. Specifically, that moving to pull

requests will not fix the fact that maintainers are usually busy people and
don't always give feedback in a punctual manner. Like Laszlo, I would also
prefer that we do not squash patch series. My biggest reason for not
squashing patch series is because when you put everything into a single
commit, I have had to review commits with 500+ files changed. Opening git
difftool on a commit like that is awful.

However, I would like to register my general endorsement for pull requests

or some other web based system of code review… and I don’t have an
Instagram account by the way :) Personally, I prefer Gerrit as I use it a lot with
coreboot and other projects. But since we are using Github for hosting, pull
requests are an easy switch and a logical choice. My main reason for being
excited about pull requests mostly has to do with the amount of manual
effort required to be a TianoCore maintainer right now. I have set up my
email filter so that the mailing list is categorized like so:

[cid:image001.png@...]



Implementing the logic to parse the contents of emails to categorize them

like this required me to define no less than 12 email filter rules in Microsoft
Outlook, and I have to change my filtering logic every time I am
added/removed from a Maintainers.txt file. I’m sure every other maintainer
has spent a time separately implementing filtering logic like I have. This helps,
but still for every thread, I have to go and check if one of the other
maintainers has already reviewed/pushed that patch series yet, and if not
review/push it. If I have ] feedback on a patch series, I have to categorize it
as awaiting response from author and check up on it from time to time,
sometimes I ping the author directly and remind them to send a new patch
series. Implementing this state machine is a lot of manual work and it kind of
feels like I’m a telephone operator in the 1950s. I greatly welcome
automation here as I am sure it will increase the number of patch series I am
able to review per hour.

Thanks,

Nate



-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Laszlo
Ersek
Sent: Friday, May 15, 2020 2:08 AM
To: rfc@edk2.groups.io; bret.barkelew@...;
devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@...>
Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull
Request based Code Review Process



On 05/15/20 06:49, Bret Barkelew via groups.io wrote:

I would far prefer the approach of individual PRs for commits to
allow

for the squash flexibility (and is the strategy I think I would
pursue

with my PRs). For example, the VarPol PR would be broken up into 9
PRs

for each final commit, and we can get them in one by one.

Ideally, each one would be a small back and forth and then in. If it

had been done that way to begin with, it would be over in a week and
a

half or so, rather than the multiple months that we’re now verging

on.

This differs extremely from how we've been working on edk2-devel (or

from how any git-based project works that I've ever been involved with).

And I think the above workflow is out of scope, for migrating the edk2

process to github.

Again, the structuring of a patch series is a primary trait. Iterating only on

individual patches does not allow for the reordering / restructuring of the
patch series (dropping patches, reordering patches, inserting patches,
moving hunks between patches).

It's common that the necessity to revise an earlier patch emerges while

reworking a later patch. For instance, the git-rebase(1) manual dedicates a
separate section to "splitting commits".

In the initial evaluation of "web forges", Phabricator was one of the

"contestants". Phabricator didn't support the "patch series" concept at all, it
only supported review requests for individual patches, and it supported
setting up dependencies between them. So, for example, a 27-patch series
would require 27 submissions and 26 dependencies.

Lacking support for the patch series concept was an immediate deal

breaker with Phabricator.

The longest patch series I've ever submitted to edk2-devel had 58 patches.

It was SMM enablement for OVMF. It went from v1 to v5 (v5 was merged),
and the patch count varied significantly:

v1: 58 patches (25 Jul 2015)

v2: 41 patches ( 9 Oct 2015)

v3: 52 patches (15 Oct 2015)

v4: 41 patches ( 3 Nov 2015)

v5: 33 patches (27 Nov 2015)



(The significant drop in the patch count was due to Mike Kinney open
sourcing and upstreaming the *real* PiSmmCpuDxeSmm driver (which was
huge work in its own right), allowing me to drop the Quark-originated
32-bit-only PiSmmCpuDxeSmm variant, from my series.)



The contribution process should make difficult things possible, even if that

complicates simple things somewhat. A process that makes simple things
simple and difficult things impossible is useless. This is what the Instagram
generation seems to be missing.

I don't know why the VariablePolicy work took months. I can see the

following threads on the list:

* [edk2-devel] [PATCH v1 0/9] Add the VariablePolicy feature

Fri, 10 Apr 2020 11:36:01 -0700



* [edk2-devel] [PATCH v2 00/12] Add the VariablePolicy feature

Mon, 11 May 2020 23:46:23 -0700



I have two sets of comments:



(1) It's difficult to tell in retrospect (because the series seem to have been

posted with somewhat problematic threading), but the delay apparently
came from multiple sources.

(1a) Review was slow and spotty.



The v1 blurb received some comments in the first week after it was posted.

But the rest of the v1 series (the actual patches) received feedback like this:

- v1 1/9: no feedback

- v1 2/9: 12 days after posting

- v1 3/9: 16 days after posting

- v1 4/9: no feedback

- v1 5/9: no feedback

- v1 6/9: no feedback

- v1 7/9: no feedback

- v1 8/9: no feedback

- v1 9/9: no feedback



(1b) There was also quite some time between the last response in the v1

thread (Apr 26th, as far as I can see), and the posting of the v2 series (May
11th).

(1c) The v2 blurb got almost immediate, and numerous feedback (on the

day of posting, and the day after). Regarding the individual patches, they
didn't fare too well:

- v2 01/12: superficial comment on the day of posting from me (not a

designated MdeModulePkg review), on the day of posting;
no

other feedback thus far

- v2 02/12: ditto

- v2 03/12: no feedback

- v2 04/12: superficial (coding style) comments on the day of posting

- v2 05/12: no feedback

- v2 06/12: no feedback

- v2 07/12: no feedback

- v2 08/12: no feedback

- v2 09/12: no feedback

- v2 10/12: no feedback

- v2 11/12: reasonably in-depth review from responsible co-maintainer

(yours truly), on the day of posting

- v2 12/12: no feedback



In total, I don't think the current process takes the blame for the delay. If

reviewers don't care (or have no time) now, that problem will not change
with the transition to github.com.

(2) The VariablePolicy series is actually a good example that patch series

restructuring is important.

(2a) The patch count went from 9 (in v1) to 12 (in v2).



(2b) And under v2, Liming still pointed out: "To keep each commit build

pass, the patch set should first add new library instance, then add the library
instance into each platform DSC, last update Variable driver to consume new
library instance."

Furthermore, I requested enabling the feature in ArmVirtPkg too, and

maybe (based on owner feedback) UefiPayloadPkg.

Thus, the v2->v3 update will most likely bring about both patch order

changes, and an increased patch count.

Thanks

Laszlo

(+Leif, +Andrew)

Sean,

On 05/19/20 18:54, Sean Brogan wrote:

Nate/Laszlo,

Regarding a squash merge workflow.  I agree it can be abused and we all
have seen terrible examples.  But a patch series that contains 500+ file
changes isn't really much better.  Just because it is broken into
multiple commits doesn't mean it is the right set of commits.

Anyway a squash merge workflow works amazingly well with and is
optimized for a web based review and PR processes.  It allows a user to
respond to changes, fix issues, learn thru the PR process, all while
keeping complete track of the progression.  Then once all "status"
checks and reviews are complete, it is squashed into a neat commit for
mainline, containing only the relevant data in the message.

So, the ask is that we don't exclude squash merge workflows.  Those
reviewing the PR can decide what is appropriate for the PR content
submitted.  Just as you would request changes to the contents (or
ordering) of a commit in a series, if the reviewers don't agree that the
PR contents should be in a single commit then obviously it shouldn't be
squashed to one.

Contributions like spelling fixes, typos, minor bug fixes, documentation
additions/fixes, etc all are great examples of PRs that can easily
leverage squash merges and this workflow significantly lowers the burden
of the contribution and review process.  This workflow is also are much
easier for casual or first time contributors.

I don't exactly know how we would enable this but I assume we could
leverage tags or make it clear in the PR description.  First step is to
get alignment that a squash merge workflow, while not appropriate for
all contributions, is not something to be excluded.

the scope for migrating the contribution & review workflows off the
mailing list and to github.com was set many months ago. That scope does
not include institutionalized changes to patch set structuring criteria.
The "git forge" evaluations that we had spent weeks/months on also
focused on how candidate systems would honor a patch series' structure;
i.e., how faithful the system would remain to the contributors' and
reviewers' shared intent, with a specific patch set.

Your proposal to "don't exclude squash merge workflows" is a trap. If we
tolerate that option -- which is obviously the sloppy, and hence more
convenient, option for some maintainers and some contributors, to the
detriment of the git history --, then almost every core maintainer will
use it as frequently as they can. In the long term, that will hurt many
consumers of the core code. It will limit the ability of people not
regularly dealing with a particular core module to file a fine-grained
bug report for that module, maybe even propose a fix. From the
regression analyst's side, if the bug report starts with "I have a
bisection log", that's already a good day. And your proposal would
destroy that option, because maintainers and people in general are
irrepairably lazy and undisciplined. We cannot post a community member
shoulder-by-shoulder with every core package reviewer/maintainer to
prevent the latter from approving a squash-on-merge, out of pure
laziness. I'm 100% sure the "option" to squash-on-merge would
*immediately* be abused for a lot more than just "typo fixes". There
isn't enough manpower to watch the watchers, so "no squash-on-merge"
needs to be a general rule.

I'm very sad that you're trying to wiggle such a crucial and intrusive
workflow change into the scope of this transition. Every time
squash-on-merge has come up over the years (regardless of this
transition), we've labeled it as one thing never to do, because it
destroys information (and/or even encourages not *creating* that
historical information in the first place, which is of course important
in reality).

Well, anyway, here's my feedback: if squash-on-merge is permitted in
edk2 or in basetools (or in any other external repository that's a hard
requirement for building edk2), that's a deal breaker for me, and I'll
hand in my resignation as a steward.

Maybe you'd consider that a win, I don't know -- but I couldn't remain a
steward with a straight face after failing to protect what I consider
one of the core values of open source / distributed development.

Thanks,
Laszlo

Hi Bret,

To be completely fair, I think we are splitting hairs on details here. I think both of us are in 90% agreement, and we are both passionate enough about our work to argue that last 10% to the grave.

I totally understand the desire for bisectability by the way. TianoCore is a huge codebase, the core modules have several extremely large functions, and very little in the way of explicit documentation. It has taken me years to learn how this beast works. I think it is possible to not squash every patch series and still maintain bisectability.

For example, your VariablePolicy patch series; we definitely want the patch that adds VariablePolicyLib to MdeModulePkg merged before the patch that adds it to OvmfPkg. But if the patch series is done carefully it can still be bisectable. In fact, bisectability will only be maintained iff we merge the entire series in the order that you/Michael sent it; if OvmfPkg gets merged first, then OvmfPkg will fail to build until the MdeModulePkg patch is merged. I don't think it would be the right thing to squash the OvmfPkg & MdeModulePkg patches together, as they really are distinct steps that you took on your journey towards making the VariablePolicy sausage.

Of course, there may be other patch series that would be logical to squash, especially if the author has not been careful to maintain bisectability. For example, I think of some patch series went a little overboard and could have been done in maybe 1-2 patches instead of 8-10. I would be happy to compromise with you and say that squashes can be done in circumstances where both the maintainer and the author agree to it.

Finally, I believe I can speak for everyone here that we all welcome your contributions. I think Mike and the rest of the community are trying to adjust the process to make contributing viable for a larger set of people. But at the same time, you must realize that TianoCore isn't just going to do everything exactly the same way that Microsoft does. You and Sean are expected to compromise with the rest of the community.

Thanks,
Nate

On 5/19/20, 1:11 PM, "rfc@edk2.groups.io on behalf of Bret Barkelew via groups.io" <rfc@edk2.groups.io on behalf of bret.barkelew@...> wrote:

I will honor Mike Kinney’s efforts with my vote of confidence.
I think we’re headed in the right direction, even with some of the things that I disagree with.

In my history with TianoCore, I have learned to not be so quick to say “this is fucking stupid”. Every time I’ve done that, I’ve later discovered the reasons behind it, and even come to the conclusion that the designers were quite clever.

That said, I want to contribute. And I won’t with the current system. I hope to be able to with the future system.

- Bret

From: Desimone, Nathaniel L<mailto:nathaniel.l.desimone@...>
Sent: Tuesday, May 19, 2020 12:59 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Bret Barkelew<mailto:Bret.Barkelew@...>; spbrogan@...<mailto:spbrogan@...>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@...<mailto:lersek@...>; Kinney, Michael D<mailto:michael.d.kinney@...>
Subject: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Hi Bret,

I believe you missed my point. I don’t want my patch series to be merged piece by piece; I want it merged all at once, in the order that I specified.

I tend to agree with Laszlo that you are choosing not to learn how to use Git properly. Commit early, commit often, perfect later, publish once is the Git best practice. You should not hide the sausage making, which is exactly what you are proposing. I find it unfortunate that you consider refusing to learn GIt best practices a mark of prestige.

Thanks,
Nate

From: <devel@edk2.groups.io> on behalf of "Bret Barkelew via groups.io" <bret.barkelew@...>
Reply-To: "devel@edk2.groups.io" <devel@edk2.groups.io>, "bret.barkelew@..." <bret.barkelew@...>
Date: Tuesday, May 19, 2020 at 12:35 PM
To: "devel@edk2.groups.io" <devel@edk2.groups.io>, "Desimone, Nathaniel L" <nathaniel.l.desimone@...>, "spbrogan@..." <spbrogan@...>, "rfc@edk2.groups.io" <rfc@edk2.groups.io>, "lersek@..." <lersek@...>, "Kinney, Michael D" <michael.d.kinney@...>
Subject: Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Nate, I believe you missed Sean’s point.

Each one of those packages should have been a separate PR.
Ergo, no information would have been lost in the squash.

Also, it’s not so much that we *can’t* learn. It’s that we choose not to. Around here, it’s a mark of prestige to not open doors with your face if it seems like there’s a better way. Makes it easier to focus on the work.

- Bret

From: Nate DeSimone via groups.io<mailto:nathaniel.l.desimone@...>
Sent: Tuesday, May 19, 2020 11:02 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@...<mailto:spbrogan@...>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@...<mailto:lersek@...>; Bret Barkelew<mailto:Bret.Barkelew@...>; Kinney, Michael D<mailto:michael.d.kinney@...>
Subject: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Hi Sean,

My recent spelling fix patch series is a good example of why this is a bad idea actually:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59779&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=fVz16E37%2BwW5pSgRxI45K7nWPDlIoS0HuI8UCGmEwjY%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59779&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cbf6d5aed67374c95ca3508d7fc2f20ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255151662145479&sdata=m66IViN3G%2BbJpBwolRXf8d3BpWQeRXs495WYxnsD85M%3D&reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59780&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=4q0lC1BSlSoQ3p0HGWwlph09HTjgJRo4nTO2Qx59%2Fjc%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59780&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cbf6d5aed67374c95ca3508d7fc2f20ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255151662155477&sdata=VuYPqwcmYTrbiYdo%2B8K5irX8k6rgMgEoC2fY8eAocWA%3D&reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59781&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=XQVSwPMXdpDJXj9nkuvq2fenwhNt6HGGZXsJwH5Bu8E%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59781&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cbf6d5aed67374c95ca3508d7fc2f20ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255151662165472&sdata=lMrhfWKBWKGkjNnXJJy7%2BisrugTi0J%2FUkmtnj7Vxb7Q%3D&reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59782&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=kCULGBc6%2Bifcn3cnPTV1odHI1ZUxuWQePN3POKKS3SM%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59782&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cbf6d5aed67374c95ca3508d7fc2f20ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255151662165472&sdata=rltVYSQcSLG2sGP4d2awDIuWV11nYQcdxvqyPxDM4XE%3D&reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59783&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=SCOhUMdNXHIymGLaw9z3JTh%2Fe2BfaJaAyEC99EkG%2Fvg%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59783&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cbf6d5aed67374c95ca3508d7fc2f20ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255151662175469&sdata=b0J%2BL4nddt3g%2FmidZO61tlkgVqrRsufOUHGjRqh1CJM%3D&reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59784&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=epET6Wk30bIHQCvEDFLkeHEfmm9tzlxRrJ%2FQAuEfQFs%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59784&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cbf6d5aed67374c95ca3508d7fc2f20ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255151662185463&sdata=zhHUUmckRdY45oYIPodqP9r3Sh4Q4t%2FZYRLULOiAERs%3D&reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59785&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C6e47f5e045f740536a0708d7fc1ed290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255081625996312&amp;sdata=N8T7HjerJVvyGg94yMWjLm%2Fw7WDdXOdby1JpOYlPeVc%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59785&data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cbf6d5aed67374c95ca3508d7fc2f20ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255151662185463&sdata=MNUfWJhjb1UfPFciUJ2dcu9uWQwUNkS3PJO%2BeMkFVxA%3D&reserved=0>

Notice that I split along package boundaries, because the maintainers for each package is a different set of people. If my patch series was squashed at merge time... how do I know who reviewed what? If the commit set is not correct.. I tend to say so in my feedback :). The only sane way to squash this series would be to have a human re-write all the commit messages, which I am against.

Generally those that prefer an easily bisectable history have such preference mostly due to the usage of validators that immediately resort bisecting as a method to root cause an issue since they tend to not understand the code very well. Edk2 already has 12 years of non-bisectable history, so this method is going to be ineffective anyway.

With regard to sending squashed commits, I understand that those who are new may have difficulty sending a properly formatted patch series, but frankly attempting to shield them from having to learn I am strongly against. I suggest that Microsoft invest in its human capital similar to how Intel does. If you cannot figure out how to send a properly formatted patch series... then do your work on the internal codebase (or perhaps MU.) Within the Intel, having the skillset to contribute to TianoCore is considered a mark of prestige, and thus needs to be earned.

TLDR, I will reject squashed commits on any packages that I maintain.

Thanks,
Nate

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sean
> Sent: Tuesday, May 19, 2020 9:54 AM
> To: rfc@edk2.groups.io; Desimone, Nathaniel L
> <nathaniel.l.desimone@...>; lersek@...;
> bret.barkelew@...; devel@edk2.groups.io; Kinney, Michael D
> <michael.d.kinney@...>
> Subject: Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review
> Process
>
> Nate/Laszlo,
>
> Regarding a squash merge workflow. I agree it can be abused and we all
> have seen terrible examples. But a patch series that contains 500+ file
> changes isn't really much better. Just because it is broken into multiple
> commits doesn't mean it is the right set of commits.
>
> Anyway a squash merge workflow works amazingly well with and is
> optimized for a web based review and PR processes. It allows a user to
> respond to changes, fix issues, learn thru the PR process, all while keeping
> complete track of the progression. Then once all "status"
> checks and reviews are complete, it is squashed into a neat commit for
> mainline, containing only the relevant data in the message.
>
> So, the ask is that we don't exclude squash merge workflows. Those
> reviewing the PR can decide what is appropriate for the PR content
> submitted. Just as you would request changes to the contents (or
> ordering) of a commit in a series, if the reviewers don't agree that the PR
> contents should be in a single commit then obviously it shouldn't be
> squashed to one.
>
> Contributions like spelling fixes, typos, minor bug fixes, documentation
> additions/fixes, etc all are great examples of PRs that can easily leverage
> squash merges and this workflow significantly lowers the burden of the
> contribution and review process. This workflow is also are much easier for
> casual or first time contributors.
>
> I don't exactly know how we would enable this but I assume we could
> leverage tags or make it clear in the PR description. First step is to get
> alignment that a squash merge workflow, while not appropriate for all
> contributions, is not something to be excluded.
>
> Thanks
> Sean
>
>
>
> On 5/19/2020 12:21 AM, Nate DeSimone wrote:
> > Hi All,
> >
> >
> >
> > I tend to agree with most of Laszlo's points. Specifically, that moving to pull
> requests will not fix the fact that maintainers are usually busy people and
> don't always give feedback in a punctual manner. Like Laszlo, I would also
> prefer that we do not squash patch series. My biggest reason for not
> squashing patch series is because when you put everything into a single
> commit, I have had to review commits with 500+ files changed. Opening git
> difftool on a commit like that is awful.
> >
> >
> >
> > However, I would like to register my general endorsement for pull requests
> or some other web based system of code review… and I don’t have an
> Instagram account by the way :) Personally, I prefer Gerrit as I use it a lot with
> coreboot and other projects. But since we are using Github for hosting, pull
> requests are an easy switch and a logical choice. My main reason for being
> excited about pull requests mostly has to do with the amount of manual
> effort required to be a TianoCore maintainer right now. I have set up my
> email filter so that the mailing list is categorized like so:
> >
> >
> >
> > [cid:image001.png@...]
> >
> >
> >
> > Implementing the logic to parse the contents of emails to categorize them
> like this required me to define no less than 12 email filter rules in Microsoft
> Outlook, and I have to change my filtering logic every time I am
> added/removed from a Maintainers.txt file. I’m sure every other maintainer
> has spent a time separately implementing filtering logic like I have. This helps,
> but still for every thread, I have to go and check if one of the other
> maintainers has already reviewed/pushed that patch series yet, and if not
> review/push it. If I have ] feedback on a patch series, I have to categorize it
> as awaiting response from author and check up on it from time to time,
> sometimes I ping the author directly and remind them to send a new patch
> series. Implementing this state machine is a lot of manual work and it kind of
> feels like I’m a telephone operator in the 1950s. I greatly welcome
> automation here as I am sure it will increase the number of patch series I am
> able to review per hour.
> >
> >
> >
> > Thanks,
> >
> > Nate
> >
> >
> >
> > -----Original Message-----
> > From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Laszlo
> > Ersek
> > Sent: Friday, May 15, 2020 2:08 AM
> > To: rfc@edk2.groups.io; bret.barkelew@...;
> > devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@...>
> > Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull
> > Request based Code Review Process
> >
> >
> >
> > On 05/15/20 06:49, Bret Barkelew via groups.io wrote:
> >
> >
> >
> >> I would far prefer the approach of individual PRs for commits to
> >> allow
> >
> >> for the squash flexibility (and is the strategy I think I would
> >> pursue
> >
> >> with my PRs). For example, the VarPol PR would be broken up into 9
> >> PRs
> >
> >> for each final commit, and we can get them in one by one.
> >
> >> Ideally, each one would be a small back and forth and then in. If it
> >
> >> had been done that way to begin with, it would be over in a week and
> >> a
> >
> >> half or so, rather than the multiple months that we’re now verging
> >
> >> on.
> >
> >
> >
> > This differs extremely from how we've been working on edk2-devel (or
> from how any git-based project works that I've ever been involved with).
> >
> > And I think the above workflow is out of scope, for migrating the edk2
> process to github.
> >
> >
> >
> > Again, the structuring of a patch series is a primary trait. Iterating only on
> individual patches does not allow for the reordering / restructuring of the
> patch series (dropping patches, reordering patches, inserting patches,
> moving hunks between patches).
> >
> >
> >
> > It's common that the necessity to revise an earlier patch emerges while
> reworking a later patch. For instance, the git-rebase(1) manual dedicates a
> separate section to "splitting commits".
> >
> >
> >
> > In the initial evaluation of "web forges", Phabricator was one of the
> "contestants". Phabricator didn't support the "patch series" concept at all, it
> only supported review requests for individual patches, and it supported
> setting up dependencies between them. So, for example, a 27-patch series
> would require 27 submissions and 26 dependencies.
> >
> >
> >
> > Lacking support for the patch series concept was an immediate deal
> breaker with Phabricator.
> >
> >
> >
> > The longest patch series I've ever submitted to edk2-devel had 58 patches.
> It was SMM enablement for OVMF. It went from v1 to v5 (v5 was merged),
> and the patch count varied significantly:
> >
> >
> >
> > v1: 58 patches (25 Jul 2015)
> >
> > v2: 41 patches ( 9 Oct 2015)
> >
> > v3: 52 patches (15 Oct 2015)
> >
> > v4: 41 patches ( 3 Nov 2015)
> >
> > v5: 33 patches (27 Nov 2015)
> >
> >
> >
> > (The significant drop in the patch count was due to Mike Kinney open
> > sourcing and upstreaming the *real* PiSmmCpuDxeSmm driver (which was
> > huge work in its own right), allowing me to drop the Quark-originated
> > 32-bit-only PiSmmCpuDxeSmm variant, from my series.)
> >
> >
> >
> > The contribution process should make difficult things possible, even if that
> complicates simple things somewhat. A process that makes simple things
> simple and difficult things impossible is useless. This is what the Instagram
> generation seems to be missing.
> >
> >
> >
> >
> >
> > I don't know why the VariablePolicy work took months. I can see the
> following threads on the list:
> >
> >
> >
> > * [edk2-devel] [PATCH v1 0/9] Add the VariablePolicy feature
> >
> > Fri, 10 Apr 2020 11:36:01 -0700
> >
> >
> >
> > * [edk2-devel] [PATCH v2 00/12] Add the VariablePolicy feature
> >
> > Mon, 11 May 2020 23:46:23 -0700
> >
> >
> >
> > I have two sets of comments:
> >
> >
> >
> > (1) It's difficult to tell in retrospect (because the series seem to have been
> posted with somewhat problematic threading), but the delay apparently
> came from multiple sources.
> >
> >
> >
> > (1a) Review was slow and spotty.
> >
> >
> >
> > The v1 blurb received some comments in the first week after it was posted.
> But the rest of the v1 series (the actual patches) received feedback like this:
> >
> >
> >
> > - v1 1/9: no feedback
> >
> > - v1 2/9: 12 days after posting
> >
> > - v1 3/9: 16 days after posting
> >
> > - v1 4/9: no feedback
> >
> > - v1 5/9: no feedback
> >
> > - v1 6/9: no feedback
> >
> > - v1 7/9: no feedback
> >
> > - v1 8/9: no feedback
> >
> > - v1 9/9: no feedback
> >
> >
> >
> > (1b) There was also quite some time between the last response in the v1
> thread (Apr 26th, as far as I can see), and the posting of the v2 series (May
> 11th).
> >
> >
> >
> > (1c) The v2 blurb got almost immediate, and numerous feedback (on the
> day of posting, and the day after). Regarding the individual patches, they
> didn't fare too well:
> >
> >
> >
> > - v2 01/12: superficial comment on the day of posting from me (not a
> >
> > designated MdeModulePkg review), on the day of posting;
> > no
> >
> > other feedback thus far
> >
> > - v2 02/12: ditto
> >
> > - v2 03/12: no feedback
> >
> > - v2 04/12: superficial (coding style) comments on the day of posting
> >
> > - v2 05/12: no feedback
> >
> > - v2 06/12: no feedback
> >
> > - v2 07/12: no feedback
> >
> > - v2 08/12: no feedback
> >
> > - v2 09/12: no feedback
> >
> > - v2 10/12: no feedback
> >
> > - v2 11/12: reasonably in-depth review from responsible co-maintainer
> >
> > (yours truly), on the day of posting
> >
> > - v2 12/12: no feedback
> >
> >
> >
> > In total, I don't think the current process takes the blame for the delay. If
> reviewers don't care (or have no time) now, that problem will not change
> with the transition to github.com.
> >
> >
> >
> >
> >
> > (2) The VariablePolicy series is actually a good example that patch series
> restructuring is important.
> >
> >
> >
> > (2a) The patch count went from 9 (in v1) to 12 (in v2).
> >
> >
> >
> > (2b) And under v2, Liming still pointed out: "To keep each commit build
> pass, the patch set should first add new library instance, then add the library
> instance into each platform DSC, last update Variable driver to consume new
> library instance."
> >
> >
> >
> > Furthermore, I requested enabling the feature in ArmVirtPkg too, and
> maybe (based on owner feedback) UefiPayloadPkg.
> >
> >
> >
> > Thus, the v2->v3 update will most likely bring about both patch order
> changes, and an increased patch count.
> >
> >
> >
> > Thanks
> >
> > Laszlo
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>

I’ll pour another cup of tea to that.

- Bret

________________________________
From: Desimone, Nathaniel L <nathaniel.l.desimone@...>
Sent: Tuesday, May 19, 2020 2:02:49 PM
To: rfc@edk2.groups.io <rfc@edk2.groups.io>; Bret Barkelew <Bret.Barkelew@...>; devel@edk2.groups.io <devel@edk2.groups.io>; spbrogan@... <spbrogan@...>; lersek@... <lersek@...>; Kinney, Michael D <michael.d.kinney@...>
Subject: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Hi Bret,

To be completely fair, I think we are splitting hairs on details here. I think both of us are in 90% agreement, and we are both passionate enough about our work to argue that last 10% to the grave.

I totally understand the desire for bisectability by the way. TianoCore is a huge codebase, the core modules have several extremely large functions, and very little in the way of explicit documentation. It has taken me years to learn how this beast works. I think it is possible to not squash every patch series and still maintain bisectability.

For example, your VariablePolicy patch series; we definitely want the patch that adds VariablePolicyLib to MdeModulePkg merged before the patch that adds it to OvmfPkg. But if the patch series is done carefully it can still be bisectable. In fact, bisectability will only be maintained iff we merge the entire series in the order that you/Michael sent it; if OvmfPkg gets merged first, then OvmfPkg will fail to build until the MdeModulePkg patch is merged. I don't think it would be the right thing to squash the OvmfPkg & MdeModulePkg patches together, as they really are distinct steps that you took on your journey towards making the VariablePolicy sausage.

Of course, there may be other patch series that would be logical to squash, especially if the author has not been careful to maintain bisectability. For example, I think of some patch series went a little overboard and could have been done in maybe 1-2 patches instead of 8-10. I would be happy to compromise with you and say that squashes can be done in circumstances where both the maintainer and the author agree to it.

Finally, I believe I can speak for everyone here that we all welcome your contributions. I think Mike and the rest of the community are trying to adjust the process to make contributing viable for a larger set of people. But at the same time, you must realize that TianoCore isn't just going to do everything exactly the same way that Microsoft does. You and Sean are expected to compromise with the rest of the community.

Thanks,
Nate

On 5/19/20, 1:11 PM, "rfc@edk2.groups.io on behalf of Bret Barkelew via groups.io" <rfc@edk2.groups.io on behalf of bret.barkelew@...> wrote:

I will honor Mike Kinney’s efforts with my vote of confidence.
I think we’re headed in the right direction, even with some of the things that I disagree with.

In my history with TianoCore, I have learned to not be so quick to say “this is fucking stupid”. Every time I’ve done that, I’ve later discovered the reasons behind it, and even come to the conclusion that the designers were quite clever.

That said, I want to contribute. And I won’t with the current system. I hope to be able to with the future system.

- Bret

From: Desimone, Nathaniel L<mailto:nathaniel.l.desimone@...>
Sent: Tuesday, May 19, 2020 12:59 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Bret Barkelew<mailto:Bret.Barkelew@...>; spbrogan@...<mailto:spbrogan@...>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@...<mailto:lersek@...>; Kinney, Michael D<mailto:michael.d.kinney@...>
Subject: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Hi Bret,

I believe you missed my point. I don’t want my patch series to be merged piece by piece; I want it merged all at once, in the order that I specified.

I tend to agree with Laszlo that you are choosing not to learn how to use Git properly. Commit early, commit often, perfect later, publish once is the Git best practice. You should not hide the sausage making, which is exactly what you are proposing. I find it unfortunate that you consider refusing to learn GIt best practices a mark of prestige.

Thanks,
Nate

From: <devel@edk2.groups.io> on behalf of "Bret Barkelew via groups.io" <bret.barkelew@...>
Reply-To: "devel@edk2.groups.io" <devel@edk2.groups.io>, "bret.barkelew@..." <bret.barkelew@...>
Date: Tuesday, May 19, 2020 at 12:35 PM
To: "devel@edk2.groups.io" <devel@edk2.groups.io>, "Desimone, Nathaniel L" <nathaniel.l.desimone@...>, "spbrogan@..." <spbrogan@...>, "rfc@edk2.groups.io" <rfc@edk2.groups.io>, "lersek@..." <lersek@...>, "Kinney, Michael D" <michael.d.kinney@...>
Subject: Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Nate, I believe you missed Sean’s point.

Each one of those packages should have been a separate PR.
Ergo, no information would have been lost in the squash.

Also, it’s not so much that we *can’t* learn. It’s that we choose not to. Around here, it’s a mark of prestige to not open doors with your face if it seems like there’s a better way. Makes it easier to focus on the work.

- Bret

From: Nate DeSimone via groups.io<mailto:nathaniel.l.desimone@...>
Sent: Tuesday, May 19, 2020 11:02 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@...<mailto:spbrogan@...>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@...<mailto:lersek@...>; Bret Barkelew<mailto:Bret.Barkelew@...>; Kinney, Michael D<mailto:michael.d.kinney@...>
Subject: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Hi Sean,

My recent spelling fix patch series is a good example of why this is a bad idea actually:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59779&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2edef9b2c759477da79708d7fc38039d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255189829127641&amp;sdata=xYwOvgWRR2emIUFhy3CG%2Frxs774JyHIhlA0%2BrzV8dlU%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59779&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2edef9b2c759477da79708d7fc38039d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255189829127641&amp;sdata=xYwOvgWRR2emIUFhy3CG%2Frxs774JyHIhlA0%2BrzV8dlU%3D&amp;reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59780&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2edef9b2c759477da79708d7fc38039d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255189829127641&amp;sdata=Fvqm3EWSpquv3QSxvh8uhAK1tSxlz%2Fwd7EeeyBSMQis%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59780&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2edef9b2c759477da79708d7fc38039d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255189829137632&amp;sdata=vi503StyynvzgVF1JO6HeL0enBF0gpne%2FmZFa5nyx9Q%3D&amp;reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59781&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2edef9b2c759477da79708d7fc38039d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255189829137632&amp;sdata=YXgZgfwFGRiHzlN92j7jaf8hPaA58iD21A483yCesB8%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59781&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2edef9b2c759477da79708d7fc38039d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255189829137632&amp;sdata=YXgZgfwFGRiHzlN92j7jaf8hPaA58iD21A483yCesB8%3D&amp;reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59782&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2edef9b2c759477da79708d7fc38039d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255189829137632&amp;sdata=Cad7XxJOMK%2FEsczlQVu3DcITjVQbC1j797Q11DbAISU%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59782&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2edef9b2c759477da79708d7fc38039d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255189829137632&amp;sdata=Cad7XxJOMK%2FEsczlQVu3DcITjVQbC1j797Q11DbAISU%3D&amp;reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59783&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2edef9b2c759477da79708d7fc38039d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255189829137632&amp;sdata=3ToBlN2v4o6ip13o7isAMg29pMcmh9SBSvMIDojvl8o%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59783&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2edef9b2c759477da79708d7fc38039d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255189829137632&amp;sdata=3ToBlN2v4o6ip13o7isAMg29pMcmh9SBSvMIDojvl8o%3D&amp;reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59784&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2edef9b2c759477da79708d7fc38039d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255189829137632&amp;sdata=jic1pWXehzaiYdq3ihpR7uXZ9R0T0XdsUsc%2FHeAgpUo%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59784&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2edef9b2c759477da79708d7fc38039d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255189829137632&amp;sdata=jic1pWXehzaiYdq3ihpR7uXZ9R0T0XdsUsc%2FHeAgpUo%3D&amp;reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59785&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2edef9b2c759477da79708d7fc38039d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255189829147624&amp;sdata=LtOhDuYjnpe1OspUg33%2BEhSxnd0fG9COnCJjSrXJM9E%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F59785&;data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2edef9b2c759477da79708d7fc38039d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255189829147624&amp;sdata=LtOhDuYjnpe1OspUg33%2BEhSxnd0fG9COnCJjSrXJM9E%3D&amp;reserved=0>

Notice that I split along package boundaries, because the maintainers for each package is a different set of people. If my patch series was squashed at merge time... how do I know who reviewed what? If the commit set is not correct.. I tend to say so in my feedback :). The only sane way to squash this series would be to have a human re-write all the commit messages, which I am against.

Generally those that prefer an easily bisectable history have such preference mostly due to the usage of validators that immediately resort bisecting as a method to root cause an issue since they tend to not understand the code very well. Edk2 already has 12 years of non-bisectable history, so this method is going to be ineffective anyway.

With regard to sending squashed commits, I understand that those who are new may have difficulty sending a properly formatted patch series, but frankly attempting to shield them from having to learn I am strongly against. I suggest that Microsoft invest in its human capital similar to how Intel does. If you cannot figure out how to send a properly formatted patch series... then do your work on the internal codebase (or perhaps MU.) Within the Intel, having the skillset to contribute to TianoCore is considered a mark of prestige, and thus needs to be earned.

TLDR, I will reject squashed commits on any packages that I maintain.

Thanks,
Nate

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sean
> Sent: Tuesday, May 19, 2020 9:54 AM
> To: rfc@edk2.groups.io; Desimone, Nathaniel L
> <nathaniel.l.desimone@...>; lersek@...;
> bret.barkelew@...; devel@edk2.groups.io; Kinney, Michael D
> <michael.d.kinney@...>
> Subject: Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review
> Process
>
> Nate/Laszlo,
>
> Regarding a squash merge workflow. I agree it can be abused and we all
> have seen terrible examples. But a patch series that contains 500+ file
> changes isn't really much better. Just because it is broken into multiple
> commits doesn't mean it is the right set of commits.
>
> Anyway a squash merge workflow works amazingly well with and is
> optimized for a web based review and PR processes. It allows a user to
> respond to changes, fix issues, learn thru the PR process, all while keeping
> complete track of the progression. Then once all "status"
> checks and reviews are complete, it is squashed into a neat commit for
> mainline, containing only the relevant data in the message.
>
> So, the ask is that we don't exclude squash merge workflows. Those
> reviewing the PR can decide what is appropriate for the PR content
> submitted. Just as you would request changes to the contents (or
> ordering) of a commit in a series, if the reviewers don't agree that the PR
> contents should be in a single commit then obviously it shouldn't be
> squashed to one.
>
> Contributions like spelling fixes, typos, minor bug fixes, documentation
> additions/fixes, etc all are great examples of PRs that can easily leverage
> squash merges and this workflow significantly lowers the burden of the
> contribution and review process. This workflow is also are much easier for
> casual or first time contributors.
>
> I don't exactly know how we would enable this but I assume we could
> leverage tags or make it clear in the PR description. First step is to get
> alignment that a squash merge workflow, while not appropriate for all
> contributions, is not something to be excluded.
>
> Thanks
> Sean
>
>
>
> On 5/19/2020 12:21 AM, Nate DeSimone wrote:
> > Hi All,
> >
> >
> >
> > I tend to agree with most of Laszlo's points. Specifically, that moving to pull
> requests will not fix the fact that maintainers are usually busy people and
> don't always give feedback in a punctual manner. Like Laszlo, I would also
> prefer that we do not squash patch series. My biggest reason for not
> squashing patch series is because when you put everything into a single
> commit, I have had to review commits with 500+ files changed. Opening git
> difftool on a commit like that is awful.
> >
> >
> >
> > However, I would like to register my general endorsement for pull requests
> or some other web based system of code review… and I don’t have an
> Instagram account by the way :) Personally, I prefer Gerrit as I use it a lot with
> coreboot and other projects. But since we are using Github for hosting, pull
> requests are an easy switch and a logical choice. My main reason for being
> excited about pull requests mostly has to do with the amount of manual
> effort required to be a TianoCore maintainer right now. I have set up my
> email filter so that the mailing list is categorized like so:
> >
> >
> >
> > [cid:image001.png@...]
> >
> >
> >
> > Implementing the logic to parse the contents of emails to categorize them
> like this required me to define no less than 12 email filter rules in Microsoft
> Outlook, and I have to change my filtering logic every time I am
> added/removed from a Maintainers.txt file. I’m sure every other maintainer
> has spent a time separately implementing filtering logic like I have. This helps,
> but still for every thread, I have to go and check if one of the other
> maintainers has already reviewed/pushed that patch series yet, and if not
> review/push it. If I have ] feedback on a patch series, I have to categorize it
> as awaiting response from author and check up on it from time to time,
> sometimes I ping the author directly and remind them to send a new patch
> series. Implementing this state machine is a lot of manual work and it kind of
> feels like I’m a telephone operator in the 1950s. I greatly welcome
> automation here as I am sure it will increase the number of patch series I am
> able to review per hour.
> >
> >
> >
> > Thanks,
> >
> > Nate
> >
> >
> >
> > -----Original Message-----
> > From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Laszlo
> > Ersek
> > Sent: Friday, May 15, 2020 2:08 AM
> > To: rfc@edk2.groups.io; bret.barkelew@...;
> > devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@...>
> > Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull
> > Request based Code Review Process
> >
> >
> >
> > On 05/15/20 06:49, Bret Barkelew via groups.io wrote:
> >
> >
> >
> >> I would far prefer the approach of individual PRs for commits to
> >> allow
> >
> >> for the squash flexibility (and is the strategy I think I would
> >> pursue
> >
> >> with my PRs). For example, the VarPol PR would be broken up into 9
> >> PRs
> >
> >> for each final commit, and we can get them in one by one.
> >
> >> Ideally, each one would be a small back and forth and then in. If it
> >
> >> had been done that way to begin with, it would be over in a week and
> >> a
> >
> >> half or so, rather than the multiple months that we’re now verging
> >
> >> on.
> >
> >
> >
> > This differs extremely from how we've been working on edk2-devel (or
> from how any git-based project works that I've ever been involved with).
> >
> > And I think the above workflow is out of scope, for migrating the edk2
> process to github.
> >
> >
> >
> > Again, the structuring of a patch series is a primary trait. Iterating only on
> individual patches does not allow for the reordering / restructuring of the
> patch series (dropping patches, reordering patches, inserting patches,
> moving hunks between patches).
> >
> >
> >
> > It's common that the necessity to revise an earlier patch emerges while
> reworking a later patch. For instance, the git-rebase(1) manual dedicates a
> separate section to "splitting commits".
> >
> >
> >
> > In the initial evaluation of "web forges", Phabricator was one of the
> "contestants". Phabricator didn't support the "patch series" concept at all, it
> only supported review requests for individual patches, and it supported
> setting up dependencies between them. So, for example, a 27-patch series
> would require 27 submissions and 26 dependencies.
> >
> >
> >
> > Lacking support for the patch series concept was an immediate deal
> breaker with Phabricator.
> >
> >
> >
> > The longest patch series I've ever submitted to edk2-devel had 58 patches.
> It was SMM enablement for OVMF. It went from v1 to v5 (v5 was merged),
> and the patch count varied significantly:
> >
> >
> >
> > v1: 58 patches (25 Jul 2015)
> >
> > v2: 41 patches ( 9 Oct 2015)
> >
> > v3: 52 patches (15 Oct 2015)
> >
> > v4: 41 patches ( 3 Nov 2015)
> >
> > v5: 33 patches (27 Nov 2015)
> >
> >
> >
> > (The significant drop in the patch count was due to Mike Kinney open
> > sourcing and upstreaming the *real* PiSmmCpuDxeSmm driver (which was
> > huge work in its own right), allowing me to drop the Quark-originated
> > 32-bit-only PiSmmCpuDxeSmm variant, from my series.)
> >
> >
> >
> > The contribution process should make difficult things possible, even if that
> complicates simple things somewhat. A process that makes simple things
> simple and difficult things impossible is useless. This is what the Instagram
> generation seems to be missing.
> >
> >
> >
> >
> >
> > I don't know why the VariablePolicy work took months. I can see the
> following threads on the list:
> >
> >
> >
> > * [edk2-devel] [PATCH v1 0/9] Add the VariablePolicy feature
> >
> > Fri, 10 Apr 2020 11:36:01 -0700
> >
> >
> >
> > * [edk2-devel] [PATCH v2 00/12] Add the VariablePolicy feature
> >
> > Mon, 11 May 2020 23:46:23 -0700
> >
> >
> >
> > I have two sets of comments:
> >
> >
> >
> > (1) It's difficult to tell in retrospect (because the series seem to have been
> posted with somewhat problematic threading), but the delay apparently
> came from multiple sources.
> >
> >
> >
> > (1a) Review was slow and spotty.
> >
> >
> >
> > The v1 blurb received some comments in the first week after it was posted.
> But the rest of the v1 series (the actual patches) received feedback like this:
> >
> >
> >
> > - v1 1/9: no feedback
> >
> > - v1 2/9: 12 days after posting
> >
> > - v1 3/9: 16 days after posting
> >
> > - v1 4/9: no feedback
> >
> > - v1 5/9: no feedback
> >
> > - v1 6/9: no feedback
> >
> > - v1 7/9: no feedback
> >
> > - v1 8/9: no feedback
> >
> > - v1 9/9: no feedback
> >
> >
> >
> > (1b) There was also quite some time between the last response in the v1
> thread (Apr 26th, as far as I can see), and the posting of the v2 series (May
> 11th).
> >
> >
> >
> > (1c) The v2 blurb got almost immediate, and numerous feedback (on the
> day of posting, and the day after). Regarding the individual patches, they
> didn't fare too well:
> >
> >
> >
> > - v2 01/12: superficial comment on the day of posting from me (not a
> >
> > designated MdeModulePkg review), on the day of posting;
> > no
> >
> > other feedback thus far
> >
> > - v2 02/12: ditto
> >
> > - v2 03/12: no feedback
> >
> > - v2 04/12: superficial (coding style) comments on the day of posting
> >
> > - v2 05/12: no feedback
> >
> > - v2 06/12: no feedback
> >
> > - v2 07/12: no feedback
> >
> > - v2 08/12: no feedback
> >
> > - v2 09/12: no feedback
> >
> > - v2 10/12: no feedback
> >
> > - v2 11/12: reasonably in-depth review from responsible co-maintainer
> >
> > (yours truly), on the day of posting
> >
> > - v2 12/12: no feedback
> >
> >
> >
> > In total, I don't think the current process takes the blame for the delay. If
> reviewers don't care (or have no time) now, that problem will not change
> with the transition to github.com.
> >
> >
> >
> >
> >
> > (2) The VariablePolicy series is actually a good example that patch series
> restructuring is important.
> >
> >
> >
> > (2a) The patch count went from 9 (in v1) to 12 (in v2).
> >
> >
> >
> > (2b) And under v2, Liming still pointed out: "To keep each commit build
> pass, the patch set should first add new library instance, then add the library
> instance into each platform DSC, last update Variable driver to consume new
> library instance."
> >
> >
> >
> > Furthermore, I requested enabling the feature in ArmVirtPkg too, and
> maybe (based on owner feedback) UefiPayloadPkg.
> >
> >
> >
> > Thus, the v2->v3 update will most likely bring about both patch order
> changes, and an increased patch count.
> >
> >
> >
> > Thanks
> >
> > Laszlo
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>

On 05/19/20 21:34, Bret Barkelew wrote:

Nate, I believe you missed Sean’s point.

Each one of those packages should have been a separate PR.

And then we get to wrangle inter-PR dependencies.

Even if github.com supports that, it's a heavy-weight tool, and should
be used sparingly. Patches in a patch series are almost always
inter-dependent in some way, which indicates that many normal patch sets
would have to be split into multiple PRs.

Ergo, no information would have been lost in the squash.

Also, it’s not so much that we *can’t* learn. It’s that we choose not to. Around here, it’s a mark of prestige to not open doors with your face if it seems like there’s a better way. Makes it easier to focus on the work.

Wrt. "open doors with your face", which I understand to be a retort to
Nate associating prestige with conforming to the current workflow:

I think the expression breaks the Code of Conduct:

https://www.tianocore.org/coc.html

"Do not insult or put down other participants"

(... Before anyone suggests that I did the same when I called
maintainers & people en bloc "irrepairably lazy and undisciplined" in my
previous mail: that's a fact about humans.

People on average perform the minimum of work they can get away with,
for satisfying requirements and for reaching goals. It's natural. That's
why we have to set high standards. So that covers "lazy".

And "undisciplined" (= ignoring rules and good practices) is evidenced
frequently, with fixed BZs left open, posted patches not referenced in
the BZs they address, BZs ignored / left un-triaged for months and
years, pending patches ignored for weeks, reviewed patches left unmerged
for days or weeks, etc. I'm not throwing around accusations, just
showing that my statement was factual, hardly an insult. OTOH "open
doors with your face" is figurative speech, and I do consider it an insult.)

Thanks,
Laszlo

Hi Laszlo,

I think both myself and Bret may have gotten a little chippy. I think both of us are passionate about our work and that shows in the debate. I am happy to forgive Bret and hopefully he is with me as well.

Thanks,
Nate

On 5/19/20, 2:22 PM, "devel@edk2.groups.io on behalf of Laszlo Ersek" <devel@edk2.groups.io on behalf of lersek@...> wrote:

On 05/19/20 21:34, Bret Barkelew wrote:
> Nate, I believe you missed Sean’s point.
>
> Each one of those packages should have been a separate PR.

And then we get to wrangle inter-PR dependencies.

Even if github.com supports that, it's a heavy-weight tool, and should
be used sparingly. Patches in a patch series are almost always
inter-dependent in some way, which indicates that many normal patch sets
would have to be split into multiple PRs.

> Ergo, no information would have been lost in the squash.
>
> Also, it’s not so much that we *can’t* learn. It’s that we choose not to. Around here, it’s a mark of prestige to not open doors with your face if it seems like there’s a better way. Makes it easier to focus on the work.

Wrt. "open doors with your face", which I understand to be a retort to
Nate associating prestige with conforming to the current workflow:

I think the expression breaks the Code of Conduct:

https://www.tianocore.org/coc.html

"Do not insult or put down other participants"

(... Before anyone suggests that I did the same when I called
maintainers & people en bloc "irrepairably lazy and undisciplined" in my
previous mail: that's a fact about humans.

People on average perform the minimum of work they can get away with,
for satisfying requirements and for reaching goals. It's natural. That's
why we have to set high standards. So that covers "lazy".

And "undisciplined" (= ignoring rules and good practices) is evidenced
frequently, with fixed BZs left open, posted patches not referenced in
the BZs they address, BZs ignored / left un-triaged for months and
years, pending patches ignored for weeks, reviewed patches left unmerged
for days or weeks, etc. I'm not throwing around accusations, just
showing that my statement was factual, hardly an insult. OTOH "open
doors with your face" is figurative speech, and I do consider it an insult.)

Thanks,
Laszlo

Agreed. :)

- Bret
________________________________
From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Nate DeSimone via groups.io <nathaniel.l.desimone@...>
Sent: Tuesday, May 19, 2020 2:35:37 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>; lersek@... <lersek@...>; Bret Barkelew <Bret.Barkelew@...>; spbrogan@... <spbrogan@...>; rfc@edk2.groups.io <rfc@edk2.groups.io>; Kinney, Michael D <michael.d.kinney@...>; Leif Lindholm (Nuvia address) <leif@...>; Andrew Fish <afish@...>
Subject: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Hi Laszlo,

I think both myself and Bret may have gotten a little chippy. I think both of us are passionate about our work and that shows in the debate. I am happy to forgive Bret and hopefully he is with me as well.

Thanks,
Nate

On 5/19/20, 2:22 PM, "devel@edk2.groups.io on behalf of Laszlo Ersek" <devel@edk2.groups.io on behalf of lersek@...> wrote:

On 05/19/20 21:34, Bret Barkelew wrote:
> Nate, I believe you missed Sean’s point.
>
> Each one of those packages should have been a separate PR.

And then we get to wrangle inter-PR dependencies.

Even if github.com supports that, it's a heavy-weight tool, and should
be used sparingly. Patches in a patch series are almost always
inter-dependent in some way, which indicates that many normal patch sets
would have to be split into multiple PRs.

> Ergo, no information would have been lost in the squash.
>
> Also, it’s not so much that we *can’t* learn. It’s that we choose not to. Around here, it’s a mark of prestige to not open doors with your face if it seems like there’s a better way. Makes it easier to focus on the work.

Wrt. "open doors with your face", which I understand to be a retort to
Nate associating prestige with conforming to the current workflow:

I think the expression breaks the Code of Conduct:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.tianocore.org%2Fcoc.html&;data=02%7C01%7CBret.Barkelew%40microsoft.com%7C0b810c962b8045eb903108d7fc3c947f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637255209426194060&amp;sdata=2nyvAPNoCddaBkvh9T4uZ5Tt%2Fpnjjwgw96YDoyiPLp8%3D&amp;reserved=0

"Do not insult or put down other participants"

(... Before anyone suggests that I did the same when I called
maintainers & people en bloc "irrepairably lazy and undisciplined" in my
previous mail: that's a fact about humans.

People on average perform the minimum of work they can get away with,
for satisfying requirements and for reaching goals. It's natural. That's
why we have to set high standards. So that covers "lazy".

And "undisciplined" (= ignoring rules and good practices) is evidenced
frequently, with fixed BZs left open, posted patches not referenced in
the BZs they address, BZs ignored / left un-triaged for months and
years, pending patches ignored for weeks, reviewed patches left unmerged
for days or weeks, etc. I'm not throwing around accusations, just
showing that my statement was factual, hardly an insult. OTOH "open
doors with your face" is figurative speech, and I do consider it an insult.)

Thanks,
Laszlo

Laszlo,

First let me be clear, there is no desire or intent in any of these conversations/discussions for anyone to feel so distraught to give up this project, let alone someone so active and involved as yourself.

The basis for my perspective goes back to the conversations we had numerous years ago about being more inclusive and enabling more of the firmware development community to contribute and be involved in this project. In my opinion this project needs help. It needs more maintainers, contributors, reviewers, testers, and active users. It needs people to write documentation, answer questions, triage bugs, and plan release cycles. Without removing some of today's barriers, support will continue to decline and relevancy of this project will decline with it.

One of the first suggestions was to evaluate the contribution and review process, looking for places in the current process that are confusing, error prone, inefficient, or hard to drive consistently. It was also important to evaluate trends in other successful open source projects. From this the process moved towards evaluating GitHub based pull requests for the contribution and review process. That gets us to this discussion and in my opinion a slightly larger scope in that we are not trying to reproduce the current process using new tools but rather adjust the process to address the discussed issues leveraging these tools.

Another request from the community discussions years ago was to add testing capabilities to remove manual work and improve quality. There has been a huge effort over the last year to enable a "core" CI system, practical/easy to use unit testing capabilities, and most recently "platform" CI. These features where developed and enabled to give contributors clear expectations for the quality needed for successful contribution. In all of these efforts, my hope has been to enable more people to join this project.

Anyway, for what it is worth, I hope this long winded response provides some background into my perspective. I'll respond to other comments below.




On 5/19/2020 1:41 PM, Laszlo Ersek wrote:

(+Leif, +Andrew)
Sean,
On 05/19/20 18:54, Sean Brogan wrote:

Nate/Laszlo,

Regarding a squash merge workflow.  I agree it can be abused and we all
have seen terrible examples.  But a patch series that contains 500+ file
changes isn't really much better.  Just because it is broken into
multiple commits doesn't mean it is the right set of commits.

Anyway a squash merge workflow works amazingly well with and is
optimized for a web based review and PR processes.  It allows a user to
respond to changes, fix issues, learn thru the PR process, all while
keeping complete track of the progression.  Then once all "status"
checks and reviews are complete, it is squashed into a neat commit for
mainline, containing only the relevant data in the message.

So, the ask is that we don't exclude squash merge workflows.  Those
reviewing the PR can decide what is appropriate for the PR content
submitted.  Just as you would request changes to the contents (or
ordering) of a commit in a series, if the reviewers don't agree that the
PR contents should be in a single commit then obviously it shouldn't be
squashed to one.

Contributions like spelling fixes, typos, minor bug fixes, documentation
additions/fixes, etc all are great examples of PRs that can easily
leverage squash merges and this workflow significantly lowers the burden
of the contribution and review process.  This workflow is also are much
easier for casual or first time contributors.

I don't exactly know how we would enable this but I assume we could
leverage tags or make it clear in the PR description.  First step is to
get alignment that a squash merge workflow, while not appropriate for
all contributions, is not something to be excluded.

the scope for migrating the contribution & review workflows off the
mailing list and to github.com was set many months ago. That scope does
not include institutionalized changes to patch set structuring criteria.
The "git forge" evaluations that we had spent weeks/months on also
focused on how candidate systems would honor a patch series' structure;
i.e., how faithful the system would remain to the contributors' and
reviewers' shared intent, with a specific patch set.

I hope the scope is to build an effective and efficient contribution process that helps current contributors deliver more while opening the door to the rest of the firmware community. It should require less effort to contribute a change to edk2 than to maintain a downstream fork. Today this is not true.

Your proposal to "don't exclude squash merge workflows" is a trap. If we
tolerate that option -- which is obviously the sloppy, and hence more
convenient, option for some maintainers and some contributors, to the
detriment of the git history --, then almost every core maintainer will
use it as frequently as they can. In the long term, that will hurt many
consumers of the core code. It will limit the ability of people not
regularly dealing with a particular core module to file a fine-grained
bug report for that module, maybe even propose a fix. From the
regression analyst's side, if the bug report starts with "I have a
bisection log", that's already a good day. And your proposal would
destroy that option, because maintainers and people in general are
irrepairably lazy and undisciplined. We cannot post a community member
shoulder-by-shoulder with every core package reviewer/maintainer to
prevent the latter from approving a squash-on-merge, out of pure
laziness. I'm 100% sure the "option" to squash-on-merge would
*immediately* be abused for a lot more than just "typo fixes". There
isn't enough manpower to watch the watchers, so "no squash-on-merge"
needs to be a general rule.

I have trouble with this line of thinking. The maintainers are and should be considered the representatives of this code base. They have a vested interest to enable this repository to work for them. If they really are viewed as "sloppy" or "lazy" then we are destined to fail anyway.

Nothing in my statement of "don't exclude squash merge workflow" requested that we allow a PR to be squashed into a single commit that you believe should be a patch series. I do think those rules will need to be defined but that is needed today anyway.

I'm very sad that you're trying to wiggle such a crucial and intrusive
workflow change into the scope of this transition.

Not "trying to wiggle" anything, just focused on providing feedback and hoping to help develop an efficient and effective process using the tools available. See intro paragraph.

Every time
squash-on-merge has come up over the years (regardless of this
transition), we've labeled it as one thing never to do, because it
destroys information (and/or even encourages not *creating* that
historical information in the first place, which is of course important
in reality).

You may have labelled it that way but given the wide spread use of this practice and my own great experiences enabling a broad team with mixed backgrounds using this practice, I personally haven't. This community is a quiet one and I believe instead of speaking up, members just choose not to get involved.

Well, anyway, here's my feedback: if squash-on-merge is permitted in
edk2 or in basetools (or in any other external repository that's a hard
requirement for building edk2), that's a deal breaker for me, and I'll
hand in my resignation as a steward.
Maybe you'd consider that a win, I don't know -- but I couldn't remain a
steward with a straight face after failing to protect what I consider
one of the core values of open source / distributed development.
Thanks,
Laszlo

Thanks
Sean

On 05/19/20 23:02, Desimone, Nathaniel L wrote:

Of course, there may be other patch series that would be logical to
squash, especially if the author has not been careful to maintain
bisectability. For example, I think of some patch series went a
little overboard and could have been done in maybe 1-2 patches
instead of 8-10. I would be happy to compromise with you and say that
squashes can be done in circumstances where both the maintainer and
the author agree to it.

Important distinction:

(a) "squashing patches" is a 100% valid operation that some situations
fully justifiedly call for. Maintainers may ask for it, and contributors
may use it with or without being asked, if the situation calls for it.

(b) "squashing patches *on merge*" is intolerable.

The difference is whether there is a final human review for the
*post-squash* state before the merge occurs.

The valid case is when the contributor squashes some patches, resubmits
the review/pull request, the reviewer approves the *complete* work
(after performing another review, which may of course be incremental in
nature), and then the series is merged exactly as it was submitted.

The invalid case (squash on merge) is when the reviewer checks /
approves the series when it still contains incremental fixes as
broken-out patches, then squashes some patches (in the worst case: all
patches into one), and then merges the result. In this (invalid) case,
the complete work, in its final state (in the way it's going to land in
the git history) has not been reviewed by either submitter or reviewer,
incrementally or otherwise. This is why squash on merge is intolerable:
it places a sequence of commits into the git history that has never been
reviewed *verbatim* by either submitter or reviewer. It's a "blind
merge", to make up another term for illustration

Squashing is a 100% valid tool, I use it all the time. Squash-on-merge
is a catastrophic process failure.

Thanks
Laszlo

When this is done in a PR with branch protections this works out differently and in my view your concerns are mitigated.

1. There isn't a partial squash operation. All reviewers know that the final output of the PR is going to 1 commit. Thus there is no confusion of what or how it is being committed to the target branch.

2. With GitHub branch protections requiring the PR only being merged if it is up-to-date with the target branch. This means you have to push the button in github to merge in target and if any conflicts occur the PR is flagged and can't be completed without user involvement. This would also give reviewers an opportunity to review the merge commit if necessary.

3. With GitHub status checks and branch policies correctly configured the builds are re-run every time the target branch changes. This means that if you have confidence in your PR gates catching most practical merge errors (at least the ones the submitter would catch) you have avoided this issue. This is why the PR builds check every thing in the tree rather than just the incoming patch.

Again, this ask was not to create a lazy process or lower the quality of the code tree. If there are legitimate gaps that a squash merge workflows creates, I am interested in finding solutions. For example, the DCO requirement would need to be addressed. But we can only start those conversations if we can get aligned on the idea.

Thanks
Sean

off-topic, but for the record:

On 05/19/20 22:10, Bret Barkelew via groups.io wrote:

In my history with TianoCore, I have learned to not be so quick to
say “this is fucking stupidâ€&#65533;. Every time I’ve done that, I’ve later
discovered the reasons behind it, and even come to the conclusion
that the designers were quite clever.

while I understand and appreciate the positive message here, that
particular present participle stands out to me like a sore thumb.

I couldn't resist, and I searched my edk2-devel archives for it (for the
four letter stem, that is), which go back to ~April 2012.

I'm reporting that in all these years, this has indeed been the first
use of the word.

(Not counting the base64 encodings of some binary files that were posted
to the list, in patches -- but those encodings hardly contain "words".)

Can we stay civil, please?

(And no, I'm not a prude; in fact I've shown such restraint in my own
word choices on this list that I can only congratulate myself.)

Thanks,
Laszlo

On 05/20/20 00:25, Sean wrote:

On 5/19/2020 1:41 PM, Laszlo Ersek wrote:

Your proposal to "don't exclude squash merge workflows" is a trap. If
we tolerate that option -- which is obviously the sloppy, and hence
more convenient, option for some maintainers and some contributors,
to the detriment of the git history --, then almost every core
maintainer will use it as frequently as they can. In the long term,
that will hurt many consumers of the core code. It will limit the
ability of people not regularly dealing with a particular core module
to file a fine-grained bug report for that module, maybe even propose
a fix. From the regression analyst's side, if the bug report starts
with "I have a bisection log", that's already a good day. And your
proposal would destroy that option, because maintainers and people in
general are irrepairably lazy and undisciplined. We cannot post a
community member shoulder-by-shoulder with every core package
reviewer/maintainer to prevent the latter from approving a
squash-on-merge, out of pure laziness. I'm 100% sure the "option" to
squash-on-merge would *immediately* be abused for a lot more than
just "typo fixes". There isn't enough manpower to watch the watchers,
so "no squash-on-merge" needs to be a general rule.

I have trouble with this line of thinking. The maintainers are and
should be considered the representatives of this code base. They
have a vested interest to enable this repository to work for them. If
they really are viewed as "sloppy" or "lazy" then we are destined to
fail anyway.

You put it very well. "They have a vested interest to enable this
repository to work for them." Key part being "*for them*".

Core maintainers are responsible for making this repository work for a
lot larger camp than just themselves. Even if squash-on-merge satisfied
the requirements that core maintainers presented, squash-on-merge would
still hurt the larger community that depends on those packages.

The core-consumer community may not necessarily participate in the
day-to-day maintenance of the core packages, but they do report bugs and
even contributes bugfixes / occasional features, when their particular
use cases require those actions.

And squash-on-merge hurts those activities, down the road, because the
git history is instrumental to analyzing and learning the code base.

For example, the question "why do we call this function here?"
immediately leads to running "git blame" (possibly a series of git-blame
commands, to navigate past code movements and such). In the end
git-blame leads to a particular commit, and that commit is supposed to
answer the question. If the commit is huge (e.g. a squash of an entire
feature), then the question is not answered, and git-blame has been
rendered useless.

Nothing in my statement of "don't exclude squash merge workflow"
requested that we allow a PR to be squashed into a single commit that
you believe should be a patch series.

If the button is there, maintainers will click it even in cases when
they shouldn't, and I won't be able to catch them. The result will not
necessarily hurt the maintainer (not at once, anyway), but it will harm
others that investigate the git history afterwards -- possibly years
later.

I can't watch all CoreFoobarPkg pull requests on github to prevent this.
On the other hand, I can, and do, monitor the edk2-devel list for
seriously mis-organized patch sets, especially for core packages where
I've formed an "I had better watch out for this core package"
impression.

I have made requests under core patch sets where I was mostly unfamiliar
with the technical subject *for the time being*, asking just for
improvements to the granularity of the series. Knowing the improved
granularity might very well help me *in the future*.


The mailing list equivalent of "squash-on-merge" would be the following:

- contributor posts v1 with patches 1/5 .. 5/5 (for example),

- reviewer requests updates A, B, and C,

- contributor posts (in response to the v1 blurb, i.e. 0/5) further
patches 6/8, 7/8, 8/8

- reviewer checks the new patches and approves them, functionally,

- maintainer says "OK let me merge this",

- maintainer applies the patches (all 8 of them) from the list, on a
local branch,

- maintainer runs a git rebase squashing the whole thing into a single
patch,

- maintainer does *not* review the result,

- maintainer opens a PR with the resultant single patch,

- CI passes,

- the patch is merged.


With the list-based process, the disaster in the last step is mitigated
in at least three spots:

- All subscribers have a reasonably good chance to notice and intervene
when the incremental fixups 6/8, 7/8, 8/8 are posted as followups to
the v1 blurb, clearly with an intent to squash.

- Because the maintainer has to do *extra work* for the squashing, the
natural laziness of the maintainer works *against* the disaster. Thus
he or she will likely not perform the local rebase & squash. Instead
they will ask the contributor to perform a *fine-grained* squash (i.e.
squash each fixup into the one original patch where the fixup
belongs), and to submit a v2 series.

- If someone interested in the git history catches (after the fact) that
the maintainer merged a significantly different patch set from what
had been posted and reviewed, they can raise a stern complaint on the
list, and next time the maintainer will now better.

(This is not a theoretical option; I low-key follow both the list
traffic and the new commits in the git history (whenever I pull). In the
past I had reported several patch application violations (mismanaged
feedback tags, intrusive updates post-review, etc). Nowadays it's gotten
quite OK, thankfully, and I'm terrified of losing those improvements.)


If we just plaster a huge squash-on-merge button or checkbox over the
web UI, it *will* be abused (maintainer laziness will work *towards* the
disaster), with only a microscopic chance for me to prevent the abuse.

It's not that "I believe" that this or that *particular* series should
not be squashed. "Not squashing" is not the exception but the rule. The
*default* approach is that the submitter incorporates incremental fixes
into the series at the right stages, they maintain a proper series
structure over the iterations, and they propose revised versions of the
series in full. Squashing is the exception; for example one reason is,
"if you separate these changes from each other, then the tree will not
build in the middle; they belong together, please squash them, and
resubmit for review".

I do think those rules will need to be defined but that is needed
today anyway.

Rules are only as good as their enforcement is.

The question is not how nice it is to use squash-on-merge in the
minuscule set of situations when it might be justified; the question is
how difficult it would be to prevent the inevitable abuses.

The list lets me advocate for proper git history hygiene reasonably
efficiently (although I still miss a bunch of warts due to lack of
capacity). With the squash-on-merge button or checkbox, the flood gates
would fly open. I won't stand for that (not as a steward anyway).

I think our world views differ fundamentally. I value the git history
*way* above my own comfort, and everyone else's (accounting for both
contributor and day-to-day maintainer roles). I guess you prefer the
reciprocal of that ratio.

Thanks,
Laszlo