“… 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

Hi Bret, This is a good point. What I am proposing is the first version of the patch series submitted as a pull request. Let the community do a complete review of the content. The submitter can

As a counterpoint: if we force a new branch or force push on every tweak, we lose the “thread” of discussion on what caused the change, what changed as a result, and the easy hook for the original

To clarify, I don't think we should allow any github-side automatism to auto-rebase pull requests. I think such rebases need to occur on personal developer machines, under human oversight, and then

Build-testing at every stage through a patch series is important for ensuring bisectability. But there's a critical ingredient to that: based on the assumption that our build system / build rules are

( Wow, "squash-on-merge" is even the *default* now? That's terrible. Unfortunately, github.com sets a very bad example with this, which is made worse by github's popularity. How can we expect

That's because the proof-of-concept list is currently subscriber-only, and subscription requests have to be manually approved -- by Phil, or by me. The PoC list contains a bunch of webhook test

s/decryption/description/ (Because I'm assuming this will turn into a wiki article at some point.) s/make add/add/ Do I understand correctly that this recommends the contributor first push