...@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 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
emind them to send a new patch
> series. Implementing this state machine is a lot of manual work and it kind of
> feels like I’m a telephone operator in the 1950s. I greatly welcome
> automation here as I am sure it will increase the number of patch series I am
> able to review per ho
> 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
50 matches
Mail list logo
