Hi Laszlo,
I am trying the following configuration that is very conservative:
actions:
queue:
method: rebase
rebase_fallback: none
name: default
The auto rebase only attempts a strict rebase. If that attempt at a strict
rebase fails
then it will show that there is a conflict that the developer must take care of.
I believe any combination of 2 PRs that have overlapping diff stat should fail
a strict rebase. The following link describes the method and rebase_fallback
settings in the queue command.
https://docs.mergify.io/actions/queue/#id2
I would be more concerned if we used a method of merge or a rebase_fallback of
merge.
Are there examples you can think of where the diff stat overlap and the strict
rebase will succeed?
Another option to consider is to define an additional 'auto-rebase' label that
is
off by default to enable the auto rebase feature. By default the PR must be
synced
with head when submitted. Only if a maintainer sets the 'auto-rebase' label
will
an auto-rebase be attempted.
I also want to make it easy for non-maintainers to submit PRs and get CI test
results.
So auto rebase may be useful for that use case. Perhaps the 'auto-rebase'
label
can be considered when the 'push' label is also set.
Thanks,
Mike
> -----Original Message-----
> From: Laszlo Ersek <ler...@redhat.com>
> Sent: Tuesday, June 22, 2021 8:17 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; devel@edk2.groups.io;
> spbro...@outlook.com; a...@kernel.org
> Cc: Peter Grehan <gre...@freebsd.org>; Ard Biesheuvel
> <ardb+tianoc...@kernel.org>; Justen, Jordan L
> <jordan.l.jus...@intel.com>; Sean Brogan <sean.bro...@microsoft.com>; Rebecca
> Cran <rebe...@bsdio.com>
> Subject: Re: [edk2-devel] [PATCH] OvmfPkg/Bhyve: clean up TPM_ENABLE remnants
>
> On 06/17/21 23:53, Kinney, Michael D wrote:
> > Hi Sean,
> >
> > Mergify had added a queue feature to handle the rebases automatically and
> > make sure
> > CI passes in the order that the PRs are being applied to the base branch.
>
> I'm opposed to *unconditional* auto-rebase.
>
> On one hand, it is indeed unreasonable to require a human to manually
> rebase a "ShellPkg/Application/AcpiViewApp" series just because a series
> for "SecurityPkg/FvReportPei" was merged a bit earlier. In other words,
> merge requests for unrelated modules should not block each other.
>
> On the other hand, auto-rebase is a bad idea if both series modify at
> least one module in common (especially if both series modify at least
> one *file* in common). In case there is a contextual conflict, even if
> the conflict can be auto-resolved, and even if that resolution
> *compiles*, it has to be reviewed by a human first.
>
> I regularly use the git-range-diff command for this.
>
> At Red Hat we've seen obscure bugs due to silent mis-merges (not in edk2
> -- in different packages); such issues are difficult to debug.
>
> Bisectability helps for sure, but only if the community treats
> bisectability with high priority in the first place. (That is, if every
> contributor builds their patch set at every stage, before submitting it
> for review.)
>
> Can we restrict the auto-rebase feature to such merge requests whose
> cumulative diffstats do not intersect?
>
> Thanks,
> Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#76848): https://edk2.groups.io/g/devel/message/76848
Mute This Topic: https://groups.io/mt/83497624/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
