Re: Email based retest request process: proposal for new pull/re-apply feature

[Patrick Robb <probb@iol.unh.edu>]

On Tue, Mar 19, 2024 at 4:37 AM zhoumin <zhoumin@loongson.cn> wrote:
>
>
> One more thing I want to confirm is whether we should apply the patch
> onto the branch commit which existed at the time when that patch was
> submitted or onto the latest tip of branch if users request doing
> rebase. Users probably request a recheck with `rebase` when the CI lab
> chose a wrong branch onto which apply the patch. I worry we may
> encounter conflicts when apply the patch onto the latest commit of the
> target branch if that branch is just updated before the request.
>
>

That's a good edge case to think about...  but I also think if the
patch no longer applies cleanly on tip of intended branch, then we
would be correct to report an apply failure there. And then the
submitter should refactor their patch so it applies, and submit again.

So I think the process is like

A) If retest is requested without rebase key, then retest "original"
dpdk artifact (either by re-using the existing tarball (unh lab) or
tracking the commit from submit time and re-applying onto dpdk at that
commit (loongson)).

B) If rebase key is included, apply to tip of the indicated branch.
If, because the branch has changed, the patch no longer applies, then
we can report an apply failure. Then, submitter has to refactor their
patch and resubmit.

In either case, report the new results with an updated test result in
the email (i.e. report "_Testing PASS RETEST #1" instead of "_Testing
PASS" in the email body).