to:nathaniel.l.desim...@intel.com>; Kinney, Michael
D<mailto:michael.d.kin...@intel.com>; Leif Lindholm (Nuvia
address)<mailto:l...@nuviainc.com>
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code
Review Process
On 5/27/2020 6:12 AM, Laszlo Ersek wrote:
On 05/28/20 00:07, Rebecca Cran wrote:
> I also tried using my openSUSE WSL installation, but it failed with:
>
> STARTTLS failed! SSL connect attempt failed error:1416F086:SSL
> routines:tls_process_server_certificate:certificate verify failed at
> /usr/lib/git/git-send-email line 1548.
That's
intel.com>; Leif Lindholm (Nuvia
address)<mailto:l...@nuviainc.com>
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code
Review Process
On 5/27/2020 6:12 AM, Laszlo Ersek wrote:
> So, it could be a MINGW64 packaging bug, perhaps.
I'm getting the same error, but w
Rebecca,
I cheated and used smtpServer = relay.apple.com and smtpEncryption = tls. Seems
relay.apple.com does not require authentication and it just worked.
I used an internal git mailing list to figure all this out, but seems the easy
button was an smtpServer setup to be easy to use with gi
On 5/27/2020 6:12 AM, Laszlo Ersek wrote:
So, it could be a MINGW64 packaging bug, perhaps.
I'm getting the same error, but with a different packaging of Git:
mine's in C:\Program Files\Git\cmd\git.exe .
It's version "git version 2.26.2.windows.1".
Of course it's possible it's just the sam
On 05/27/20 03:52, Bret Barkelew wrote:
> So, today I followed the Wiki (that I had never seen) and now I’m staring
> down the barrel of this fellow…
> [cid:image002.png@01D6338E.D6C64920]
>
> [Not using SSL_VERIFY_PEER due to out-of-date IO::Socket::SSL.
> To use SSL please install IO::Socke
oups.io
Sent: 27 May 2020 02:53
To: Andrew Fish ; Laszlo Ersek
Cc: devel@edk2.groups.io; spbro...@outlook.com; r...@edk2.groups.io; Desimone,
Nathaniel L ; Kinney, Michael D
; Leif Lindholm (Nuvia address)
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code
Review
Fish
Cc: Bret Barkelew ; devel@edk2.groups.io
; spbro...@outlook.com ; Desimone,
Nathaniel L ; Kinney, Michael D
; Leif Lindholm (Nuvia address)
; Samer El-Haj-Mahmoud
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code
Review Process
I agree with Andrew. I also
; Mike Kinney
> ; Leif Lindholm (Nuvia address)
>
> Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based
> Code Review Process
>
> On 05/25/20 20:28, Andrew Fish wrote:
> >
> >
> >> On May 25, 2020, at 11:10 AM, Laszlo Ersek wrote:
> >
On 05/25/20 20:28, Andrew Fish wrote:
>
>
>> On May 25, 2020, at 11:10 AM, Laszlo Ersek wrote:
>>
>> Hi Andrew,
>>
>> On 05/25/20 06:09, Andrew Fish wrote:
>>
>>> I also found I had to Bing/Google to find the detailed instructions I
>>> needed as a developer, as the Wiki seems to assume you just
...@edk2.groups.io; bret.barke...@microsoft.com; Kinney, Michael D
; devel@edk2.groups.io; ler...@redhat.com
Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based
Code Review Process
On 5/14/20 3:26 PM, Bret Barkelew via groups.io wrote:
> I feel like this process is a g
> On May 25, 2020, at 11:10 AM, Laszlo Ersek wrote:
>
> Hi Andrew,
>
> On 05/25/20 06:09, Andrew Fish wrote:
>
>> I also found I had to Bing/Google to find the detailed instructions I
>> needed as a developer, as the Wiki seems to assume you just know the
>> Linux kernel patch process. That
Hi Andrew,
On 05/25/20 06:09, Andrew Fish wrote:
> I also found I had to Bing/Google to find the detailed instructions I
> needed as a developer, as the Wiki seems to assume you just know the
> Linux kernel patch process. That feels like an area we can improve.
(apologies if I've lost context; p
athaniel L
> <mailto:nathaniel.l.desim...@intel.com>; Bret Barkelew
> <mailto:bret.barke...@microsoft.com>; Kinney, Michael D
> <mailto:michael.d.kin...@intel.com>; Leif Lindholm (Nuvia address)
> <mailto:l...@nuviainc.com>
> Subject: [EXTERNAL] Re: [edk2-devel] [edk2
On 05/22/20 07:48, Bret Barkelew wrote:
> In Mu we have a similar problem of keeping track of what features/bugs
> have already been upstreamed and when can they be dropped during an
> upstream integration, so that's the more personal interest I have in
> such automation.
Proposal:
- Whenever up
arke...@microsoft.com>; Kinney, Michael
D<mailto:michael.d.kin...@intel.com>; Leif Lindholm (Nuvia
address)<mailto:l...@nuviainc.com>
Subject: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code
Review Process
> On May 21, 2020, at 6:30 AM, Laszlo Ersek wrote
mone, Nathaniel
L<mailto:nathaniel.l.desim...@intel.com>;
spbro...@outlook.com<mailto:spbro...@outlook.com>;
r...@edk2.groups.io<mailto:r...@edk2.groups.io>; Kinney, Michael
D<mailto:michael.d.kin...@intel.com>
Subject: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Co
> On May 21, 2020, at 6:30 AM, Laszlo Ersek wrote:
>
> 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 conve
> On May 20, 2020, at 10:21 AM, Sean wrote:
>
> 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 commi
Laszlo,
I appreciate the back and forth. I find email a challenge for this type
of discussion because it leaves so much to individual interpretation and
bias. Anyway Thank you for having the discussion. I hope others with
opinions feel empowered to chime in and help this RFC go in the
dire
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 th
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�. Every time I’ve done that, I’ve
> later
> discovered the reasons behind it, and even come to the concl
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 c
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
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 ye
Lindholm (Nuvia address) ; Andrew Fish
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
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 E
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
] 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
.@microsoft.com>;
spbro...@outlook.com<mailto:spbro...@outlook.com>;
r...@edk2.groups.io<mailto:r...@edk2.groups.io>;
ler...@redhat.com<mailto:ler...@redhat.com>; Kinney, Michael
D<mailto:michael.d.kin...@intel.com>
Subject: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] G
(+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
>
mailto:ler...@redhat.com>; Kinney, Michael
D<mailto:michael.d.kin...@intel.com>
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
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 On Behalf Of Sean
> Sent: Tuesday, May 19, 2020 9:54 AM
> To: r...@edk2.groups.io; Desimone, Nathaniel L
> ; ler...@
-Original Message-
> From: devel@edk2.groups.io On Behalf Of Sean
> Sent: Tuesday, May 19, 2020 9:54 AM
> To: r...@edk2.groups.io; Desimone, Nathaniel L
> ; ler...@redhat.com;
> bret.barke...@microsoft.com; devel@edk2.groups.io; Kinney, Michael D
>
> Subject: Re: [edk2-d
> 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
> 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 maint
tch series I am able to review per hour.
Thanks,
Nate
-Original Message-
From: r...@edk2.groups.io On Behalf Of Laszlo Ersek
Sent: Friday, May 15, 2020 2:08 AM
To: r...@edk2.groups.io; bret.barke...@microsoft.com; devel@edk2.groups.io; Kinney,
Michael D
Subject: Re: [EXTERNAL] Re: [edk2
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 ot
ubject: 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 pursu
d.kin...@intel.com>
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 th
On 5/15/20 1:34 AM, Laszlo Ersek wrote:
On 05/14/20 23:26, Bret Barkelew via groups.io wrote:
It’s code management for the Instagram generation
I find this an extremely good characterization!
And, I find the fact soul-destroying.
I was working on a web project recently, and apparently pe
r...@edk2.groups.io>; Bret
Barkelew<mailto:bret.barke...@microsoft.com>;
devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Kinney, Michael
D<mailto:michael.d.kin...@intel.com>
Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based
Code Review Pr
Kinney, Michael
D<mailto:michael.d.kin...@intel.com>;
devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based
Code Review Process
On 05/14/20 23:26, Bret Barkelew via groups.io wrote:
> It’s code management for the Ins
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,
On 05/14/20 23:26, Bret Barkelew via groups.io wrote:
> It’s code management for the Instagram generation
I find this an extremely good characterization!
And, I find the fact soul-destroying.
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/
l.d.kin...@intel.com>
Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based
Code Review Process
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 sing
; r...@edk2.groups.io
> Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc]
> GitHub Pull Request based Code Review Process
>
> 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 m
On 5/14/20 3:26 PM, Bret Barkelew via groups.io wrote:
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, ease of contribution, and approaches
the
>;
devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
ler...@redhat.com<mailto:ler...@redhat.com>;
r...@edk2.groups.io<mailto:r...@edk2.groups.io>; Kinney, Michael
D<mailto:michael.d.kin...@intel.com>
Subject: RE: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Re
of the topic
branch anyway, with git-range-diff, and compare the interdiff against my
earlier feedback.
Thanks!
Laszlo
>
> - Bret
>
> From: Laszlo Ersek via groups.io<mailto:lersek=redhat@groups.io>
> Sent: Monday, May 11, 2020 12:39 PM
> To: devel@edk2.groups.io<
<mailto:lersek=redhat@groups.io>
Sent: Monday, May 11, 2020 12:39 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Kinney, Michael
D<mailto:michael.d.kin...@intel.com>;
r...@edk2.groups.io<mailto:r...@edk2.groups.io>
Subject: [EXTERNAL] Re: [edk2-devel] [edk2-
On 05/11/20 03:37, Michael D Kinney wrote:
> There was feedback from Laszlo related to rebase for
> pull requests using the current CI process.
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 develop
On 05/10/20 23:43, Rebecca Cran wrote:
> Mike,
>
> On 5/10/20 3:29 PM, Michael D Kinney wrote:
>
>> 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 shoul
On 05/10/20 23:29, Michael D Kinney wrote:
> 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 should be
> run and if they should run automatica
On 05/09/20 06:22, Ni, Ray wrote:
> 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 migrated to Github. People don't use it because it'
On 05/09/20 04:59, Michael D Kinney wrote:
> 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 email-based code review process and commit m
Hi Ray,
Comments below.
Mike
> -Original Message-
> From: Ni, Ray
> Sent: Friday, May 8, 2020 9:23 PM
> To: r...@edk2.groups.io; Kinney, Michael D
> ; devel@edk2.groups.io
> Subject: RE: [edk2-rfc] GitHub Pull Request based Code
> Review Process
>
> Mike,
> It's a huge improvement to m
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 tianocore/edk2 repo as of May 10, 2020.
https://github.com/tianocore/edk2-codereview
I have updated
a Cran
> Sent: Sunday, May 10, 2020 2:44 PM
> To: devel@edk2.groups.io; Kinney, Michael D
> ; r...@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-rfc] GitHub Pull
> Request based Code Review Process
>
> Mike,
>
> On 5/10/20 3:29 PM, Michael D Kinney wrote:
>
&
Mike,
On 5/10/20 3:29 PM, Michael D Kinney wrote:
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 should be
run and if they should run automatically on every
l@edk2.groups.io On
> Behalf Of Rebecca Cran
> Sent: Saturday, May 9, 2020 11:25 AM
> To: devel@edk2.groups.io; Kinney, Michael D
> ; r...@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-rfc] GitHub Pull
> Request based Code Review Process
>
> On 5/8/20 8:59 PM, Michael D Kin
On 5/8/20 8:59 PM, Michael D Kinney wrote:
* Perform final review of patches and commit message tags. If there are not
issues, set the `push` label to run final set of CI checks and auto merge
the pull request into master.
What's the difference between the CI that runs when a use
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 migrated to Github. People don't use it because it's not accepted by
community. Your process
tries
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 email-based code review process and commit message
requirements are documented in Readme.md or Readme.r
64 matches
Mail list logo
