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

[zhoumin]

On Tue, Mar 19, 2024 at 5:30PM, Patrick Robb wrote:
> On Tue, Mar 19, 2024 at 4:37 AM zhoumin <zhoumin at 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.
Yes, it is more reasonable for submitter.
> 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.
Thanks for making the applying process more clear.
> 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).
Yes, I agree with this approach and reporting a new title for the retest 
result is necessary.