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 (#76846): https://edk2.groups.io/g/devel/message/76846 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] -=-=-=-=-=-=-=-=-=-=-=-
