From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C220343B58; Tue, 20 Feb 2024 19:24:56 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 55A91402DE; Tue, 20 Feb 2024 19:24:56 +0100 (CET) Received: from mail-oo1-f41.google.com (mail-oo1-f41.google.com [209.85.161.41]) by mails.dpdk.org (Postfix) with ESMTP id 2E4A1402A7 for ; Tue, 20 Feb 2024 19:24:55 +0100 (CET) Received: by mail-oo1-f41.google.com with SMTP id 006d021491bc7-59a9a737273so1139939eaf.1 for ; Tue, 20 Feb 2024 10:24:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1708453494; x=1709058294; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mozlnFjcOfQd/sI5wlFLT1PMgUzrSCx2YQwoJcWDP2I=; b=DplH4L6MDO+UeJzIfRkJcOoxwUF6Z//1HVbyBPACogOmqAz2N+IcO3qALNjRH15FcL OWWhCHZERw7xbVazOXRnYOMEzndc49XW6XOb1OQmbUmoQK6mJv2qw6bVWKdG3AzK02+Q tGNvjT2KklpfSsDWwhiVw2d1QCOvfECtmpUro= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708453494; x=1709058294; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mozlnFjcOfQd/sI5wlFLT1PMgUzrSCx2YQwoJcWDP2I=; b=OnwzhkudvtL3j53WLSW3OTKvN0bBCOOEdGCnlCSpjOs+i2n79WD6cetbYSKA41IQSS htl7qGyTlA3KLhEbIDiRkIsR/KKIG7D6VBEpCXfTV0LsiGhZKUElR4wVmY/zmUBvPa86 EQTuTeWyHP4EOcASMv1ZqN1jQli/WeM7E796SyrszP3DFqHiUeQH13rSV0JJyh3PvXAe Qgj2Zutmsp3yuuH4tgzKy0AVN/hpXXzsx9jep7P+EgO2n2gCRVhrb33TPvhh57YxPwGi ImaArEi7NFhtDj/2AKOjhWRIUpf4AMQoQPB1HpjI8IxDR6Scn5jF7ifmppFRnX7jlOq/ MgdA== X-Forwarded-Encrypted: i=1; AJvYcCV9rTkg0TfaDjQeED5yrPc+3gMX3SR1cUTq/EqfiU3wykpo7QaMUi+pXNgoQF8UYi60339HcCfAQWCERUg= X-Gm-Message-State: AOJu0YyAalMrIv9QlGrzOwJbK6yFImixkBWlrT5pEIKsGy9Eno60l1PD C6YA9WBcvNYliCDXQghZcJ2ZaJ4cVkPbYBJ1fLcAHg0YNhpVJj8eoeTEgnTGlWenrWHKP+VzyWF xMWeqgLXSYbUpaXB1VLlfMBzcdlh6RkGdS6dn1w== X-Google-Smtp-Source: AGHT+IHVoQnDk/xT1C0HA3lDTzdicEXCP3pYSdhHE7Q59Is8PANxtOyni2Jlcki17JKC/DKnWLbF4OJqcx5tKu2ik24= X-Received: by 2002:a05:6820:b4b:b0:59f:efc9:fd63 with SMTP id dg11-20020a0568200b4b00b0059fefc9fd63mr4430055oob.7.1708453494387; Tue, 20 Feb 2024 10:24:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Patrick Robb Date: Tue, 20 Feb 2024 13:24:43 -0500 Message-ID: Subject: Re: Email based retest request process: proposal for new pull/re-apply feature To: Aaron Conole Cc: ci@dpdk.org, dev@dpdk.org, zhoumin Content-Type: multipart/alternative; boundary="000000000000a60f810611d453e6" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --000000000000a60f810611d453e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 20, 2024 at 1:12=E2=80=AFPM Aaron Conole w= rote: > > Why not something like: > > Recheck-request: [attribute-list],[test-list]... > > For example, then we can do: > > Recheck-request: rebase=3D[identifier],.... > > where identifier is a branch specifier (or the word 'latest')? > I hadn't thought about the option of allowing branch specifiers. Agree that allowing a human correction process for the pw_maintainer_cli.py script choosing the wrong branch sounds helpful. My original idea was offering 2 options (test original artifact, or re-apply on latest). Do we want to support for checking out to a specific commit and re-applying there? I figured that would not be worth it (too much of a niche case), but your comments are making me reconsider. > > That lets us fixup if the branch picker script guessed a wrong branch. > > Just spit-balling on syntax. > > > That said, I agree - if a rebase has been requested, all tests need to > be rerun. Maybe we should consider that the test labels should be added > with a run number or something? Or we could also include that the run > is a rerun. That way for labs that don't currently support the recheck > request framework, we can easily tell that they weren't re-tried. > > so re-report with a modified test label? That is good in that it shows th= e behavior more clearly. But, it also means we will not overwrite any fails. So the fail will still be there, and the patchwork patch page will grow a huge table. Maybe this is fine. Also raises the point of getting more coverage for the retest framework at other labs. I will email Min Zhou regarding how he uses the dpdk-ci project for the loongson build jobs and see how well that can integrate with the get_reruns.py script. --000000000000a60f810611d453e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Feb 20, 2024 at 1:12=E2=80=AFPM A= aron Conole <aconole@redhat.com> wrote:

Why not something like:

Recheck-request: [attribute-list],[test-list]...

For example, then we can do:

Recheck-request: rebase=3D[identifier],....

where identifier is a branch specifier (or the word 'latest')?
<= /blockquote>
I hadn't thought about the option of allowing=C2=A0bra= nch=C2=A0specifiers. Agree that allowing a human correction process for the= pw_maintainer_cli.py script choosing the wrong branch sounds helpful.

My original idea was offering 2 options (test original= artifact, or re-apply on latest). Do we want to support for checking out t= o a specific commit and re-applying there? I figured that would not be wort= h it (too much of a niche case), but your comments are making me reconsider= .=C2=A0
=C2=A0

That lets us fixup if the branch picker script guessed a wrong branch.

Just spit-balling on syntax.


That said, I agree - if a rebase has been requested, all tests need to
be rerun.=C2=A0 Maybe we should consider that the test labels should be add= ed
with a run number or something?=C2=A0 Or we could also include that the run=
is a rerun.=C2=A0 That way for labs that don't currently support the re= check
request framework, we can easily tell that they weren't re-tried.

so re-report with a modified test label? That is good in= that it shows the behavior more clearly. But, it also means we will not ov= erwrite any fails. So the fail will still be there, and the patchwork patch= page will grow a huge table. Maybe this is fine.=C2=A0

= Also raises the point of getting more coverage for the retest framework at = other labs. I will email Min Zhou regarding how he uses the dpdk-ci project= for the loongson build jobs and see how well that can integrate with the g= et_reruns.py script.

--000000000000a60f810611d453e6--