Hi Sean, My recent spelling fix patch series is a good example of why this is a bad idea

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

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

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

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

Hi Bret, Which points are you disagreeing? 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

I agree with some of your points, but I don’t believe that this calls for dependencies at all. If a PR can pass CI with the changes, it’s functionally unordered. And if a PR can’t, it has to

“… boundless and bare, The lone and level sands stretch far away.” - Bret Sent: Friday, May 15, 2020 12:34 AM To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Bret

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

I find this an extremely good characterization! And, I find the fact soul-destroying. Laszlo

Sorry- I wasn't more clear with my initial message. We meant with this forum here. The discussion in the earlier forum brought up several great points and outlined a pretty decent list of must haves

Agreed. Responsibility to verify the commit message when squashing is always something to be aware of. With Github, the one who presses the “Close and Merge” (or whatever it’s called) button

Bret, If the original submission is a single patch, and the code review generates changes that are added as additional patches for review, but the intent in the end is still a single patch, then

I feel like this process is a good compromise. It’s not perfect (frankly, I’m a fan of enforced squash merges, which can maintain bisectability if managed well), but it allows for rapid iteration,

Leif, Ray, I have not seen any discussion on this thread since March(!)... Please see my comments below.

Here's an example why the above procedure (i.e., strict & lock-step versioning) is important: https://bugzilla.tianocore.org/show_bug.cgi?id=2719 When looking at a particular commit in edk2, for

Hi Matthew, I didn't provide any feedback in this specific thread because I thought our discussion earlier was sufficient feedback from me. (just commenting on the particular "we haven't had any

Since we haven't had any feedback and the deadline is quickly approaching. We are going to move ahead by creating a new repo inside of TianoCore and creating patches post-stable tag and submit them to

For example if a branch covers changes to multiple specifications, as described elsewhere. Or if it simply makes sense due to content size. It is possible, now we've migrated to .rst for edk2, that we

This is a github.com limitation. And the email archive mitigates it. In the current process, when I review v2 of a 10-part series, I have one Thunderbird window open with the v1 thread, containing