Patrick Robb <pr...@iol.unh.edu> writes: > 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.
+1 > 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. That makes sense to me. > 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). Ack - makes sense here too.
