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

Are there any additional comments on the code first process for UEFI specifications? When should we expect the process to *actually* start being used? Thanks, --Samer

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

Agreed. :) - Bret ________________________________ Sent: Tuesday, May 19, 2020 2:35:37 PM To: devel@edk2.groups.io <devel@edk2.groups.io>; lersek@... <lersek@...>; Bret Barkelew

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

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

I’ll pour another cup of tea to that. - Bret ________________________________ Sent: Tuesday, May 19, 2020 2:02:49 PM To: rfc@edk2.groups.io <rfc@edk2.groups.io>; Bret Barkelew

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

(+Leif, +Andrew) Sean, 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

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

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

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

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