On Tue, Mar 19, 2024 at 5:30PM, Patrick Robb wrote:
On Tue, Mar 19, 2024 at 4:37 AM zhoumin <zhou...@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.
