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

Hi Ray, Comments below. Mike

Hello, I have added the following repository to TianoCore to support the evaluation of the GitHub pull request based code review process and the email archive webbook. This is a copy of

Rebecca, I agree that the first version should rerun CI checks on every time commits are added to a PR or there is a forced push to the PR. Perhaps we should use Draft Pull Requests as a way to

Rebecca, There is no difference between CI checks run during code review and the final CI checks before merge. I think it is an interesting conversation to decide how many times those CI checks

Mike, It's a huge improvement to me as an Outlook user if pull-request-based review is enabled! Please help me to understand: The pull-request-based review has been enabled naturally when edk2 was

Hello, This is a proposal to change from the current email-based code review process to a GitHub pull request-based code review process for all repositories maintained in TianoCore. The current

Hi, I am trying to test if the enrollment of Authenticated Variables is possible with verification of signature with different key sizes. File: AuthService.c :: Function: VerifyTimeBasedPayload() ->

Hello Tianocore Community, I’m submitting an RFC, proposing the movement of the basetools folder in edk2 to a separate repo and treated as a separate python project. We talked about it during the

Acked-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>

Hi Aaron. (I'm responding through the groups.io webui because it's way too late for a full email fetch now. So the threading & quoting will most likely be broken. Sorry about that.) The

Hi Lazslo, thanks for the comments. My apologies - the actual virt-install command our Q/A team is using is this (which has extra args for a kick start file): virt-install --name guest-31156337

This is by-design. The behavior is expected, and your virt-install command line is wrong. The "--location" parameter invokes a direct kernel boot. When you pass a local ISO image with "--location",