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 3F90DA0547; Wed, 21 Apr 2021 17:03:14 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 03DCB41AC8; Wed, 21 Apr 2021 17:03:14 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id 71D22410F9 for ; Wed, 21 Apr 2021 17:03:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619017391; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xsKmizWf3Zi5Wiauc/OXitXTwJx2K3h8wJEUiRVFdrs=; b=F9nlKpzCbrfmFq3bu+2WBpiTIK1zG1Uyjwkftjm1varb47XuFaH1UUFVKwEk+GQzWeu/4X dOn/yZ1mjZ0F1QsHQ/35V9vOXKUKVPB/ubtC1JnxuXIpBwCr6bgZT646cS7qvFATJxUJ6y UXv4rasPBDDc9KXG8aefr7P/YkRyy2o= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-479-3rP2vObFP4q9PUANPgI0TA-1; Wed, 21 Apr 2021 11:03:00 -0400 X-MC-Unique: 3rP2vObFP4q9PUANPgI0TA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B3A6D8030A0; Wed, 21 Apr 2021 15:02:58 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (ovpn-115-145.rdu2.redhat.com [10.10.115.145]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AE9EF1000358; Wed, 21 Apr 2021 15:02:52 +0000 (UTC) From: Aaron Conole To: Thomas Monjalon Cc: David Marchand , Bruce Richardson , dev , ci@dpdk.org, Michael Santana , Lincoln Lavoie , dpdklab References: <20210413150425.GA1185@bricha3-MOBL.ger.corp.intel.com> <2009041.gKtNCFKaKa@thomas> Date: Wed, 21 Apr 2021 11:02:51 -0400 In-Reply-To: <2009041.gKtNCFKaKa@thomas> (Thomas Monjalon's message of "Tue, 13 Apr 2021 17:17:06 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=aconole@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Subject: Re: [dpdk-dev] [dpdk-ci] [RFC] Proposal for allowing rerun of tests 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 Sender: "dev" Thomas Monjalon writes: > 13/04/2021 17:04, Bruce Richardson: >> On Tue, Apr 13, 2021 at 04:59:00PM +0200, David Marchand wrote: >> > On Tue, Apr 13, 2021 at 4:47 PM Thomas Monjalon wrote: >> > > >> > > 13/04/2021 15:50, Aaron Conole: >> > > >> > > > One proposal we (Michael and I) have toyed with for our lab is having >> > > > the infrastructure monitor patchwork comments for a restart flag, and >> > > > kick off based on that information. Patchwork tracks all of the >> > > > comments for each patch / series so we could look at the series that >> > > > are still in a state for 'merging' (new, assigned, etc) and check the >> > > > patch .comments API for new comments. Getting the data from PW should >> > > > be pretty simple - but I think that knowing whether to kick off the >> > > > test might be more difficult. We have concerns about which messages we >> > > > should accept (for example, can anyone ask for a series to be rerun, and >> > > > we'll need to track which rerun messages we've accepted). The >> > > > convention needs to be something we all can work with (ie: /Re-check: >> > > > [checkname] or something as a single line in the email). >> > > > >> > > > This is just a start to identify and explain the concern. Maybe there >> > > > are other issues we've not considered, or maybe folks think this is a >> > > > terrible idea not worth spending any time developing. I think there's >> > > > enough use for it that I am raising it here, and we can discuss it. >> > > >> > > First question: WHO should be allowed to ask for a re-run? >> > > - everybody >> > > - patchwork delegate >> > >> > Patchwork delegate requires to maintain a map between pw logins and an >> > actual mail address (if we go with email for the second point). >> > >> > > - a list of maintainers >> > >> > I'd vote on any maintainer from MAINTAINERS, _but_ it must be from the >> > files in the repo, not in the series being tested. >> > So maybe the easier is to have an explicit list... ? I agree with using the MAINTAINERS file from the repo. >> > >> > - author >> > Just listing this option for discussion, but this is dangerous, as any >> > user could then call reruns. >> > >> >> I would tend towards including this, on the basis that any author can >> already get a re-run just be resubmitting a new version of their patchset. >> This just simplifies that for all concerned. > > I agree, and it would be very convenient for authors hitting > a strange failure: they can double check without bothering maintainers. +1