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 B6A0042661; Thu, 28 Sep 2023 14:32:01 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9A34D40273; Thu, 28 Sep 2023 14:32:01 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 22CF64021D for ; Thu, 28 Sep 2023 14:32:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695904319; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HItLUpKI5jlZLbTaUqIYMY1AuAMT84PdVIz2Y/HVdK0=; b=bYTUOm3nav0Kg2usWSDeRI/b7N9CbL24yDpX78xk51CBAeCQiLMwpEQhlnqdLuwIW5Xv13 aQJ6CBXWS/6x+fxQC1PxbHzdQ7y3ZjN2Lwd6c0xp8p7TL5WKwM30E9CtEAWc4GCQs0RybT lhnDJyw9U2IPpOVL6wjQ608m/B7f+kY= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-689-sAdMp5zfPleJx5ZoaAk0-g-1; Thu, 28 Sep 2023 08:31:57 -0400 X-MC-Unique: sAdMp5zfPleJx5ZoaAk0-g-1 Received: by mail-lj1-f199.google.com with SMTP id 38308e7fff4ca-2bffd454256so193755671fa.1 for ; Thu, 28 Sep 2023 05:31:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695904316; x=1696509116; h=content-transfer-encoding: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=HItLUpKI5jlZLbTaUqIYMY1AuAMT84PdVIz2Y/HVdK0=; b=gh1DYyHaPHvWCXm41tdOhPViC2yk3Kc1jlSpObgDcgG8vRGDqJMO2B1sySvMiDmWvJ UKukJnmq+ZHSs338sbSx89IbRsyA8fFps/KCEMIufJSeWECO5ISPmUU+RcLmWh6YoDxU 5GFItjsiXHwcz754B6rAdHYSkZsPN4HGmDn0hkDLePMXQxknIcsM7ZVLIX1tbr0Dhzwr xLP7Df6f2JwqXRzPxylS8kWJjRFHTzGDYMyGiy3MqEcL9VALYiYJfgdwT9l0fxxrJw5t B/rkZlhXFX28FSqZZ7VScUkX0i9A3eH1jKtQY8Q89X7QOoqgkyG3/JcMr/aecyAlnjEO rIFw== X-Gm-Message-State: AOJu0YyQ8tW/IBDU2yjlW/t4wgfnCJDCAjm3JhEWxKCvZfvsPtYUE2Df JwhA+T4NJiVPMtbvg62OmVl7Su0aud9H2YxVIYcTNDIB72WJDqmHgbaFxbkq27EkkmCO9IarG/4 f7hV/pSbrxo4v6O4P4g== X-Received: by 2002:a2e:9914:0:b0:2c0:2ab7:9aae with SMTP id v20-20020a2e9914000000b002c02ab79aaemr1047567lji.11.1695904316197; Thu, 28 Sep 2023 05:31:56 -0700 (PDT) X-Google-Smtp-Source: AGHT+IELUi6QLTTnt765vvzejNt5hfa4SGr5CpUZUw00xFBlVBqK7KGtSz+xU4BQZWRzGIHBbuoHD8UUZM9iOQet9Ks= X-Received: by 2002:a2e:9914:0:b0:2c0:2ab7:9aae with SMTP id v20-20020a2e9914000000b002c02ab79aaemr1047547lji.11.1695904315760; Thu, 28 Sep 2023 05:31:55 -0700 (PDT) MIME-Version: 1.0 References: <26230939.ouqheUzb2q@thomas> In-Reply-To: From: David Marchand Date: Thu, 28 Sep 2023 14:31:44 +0200 Message-ID: Subject: Re: Apply Patchseries Script To: Aaron Conole Cc: Patrick Robb , Thomas Monjalon , ci@dpdk.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org On Thu, Sep 28, 2023 at 2:05=E2=80=AFPM Aaron Conole w= rote: > > Patrick Robb writes: > > > On Wed, Sep 27, 2023 at 4:22=E2=80=AFPM Thomas Monjalon wrote: > > > > 27/09/2023 18:31, Patrick Robb: > > > > > 2. Do not apply and run if the series is an RFC series > > > > Not sure about this requirement. > > What is the problem in running tests on RFC? > > > > I see that currently ovsrobot and UNH Lab have rules saying don't test = on RFC series, and Loongson and Intel do test on > > RFC series. I'm guessing the thinking was something like "RFC patches a= re at least one stage away from merge, and > > probably do not represent the final state of the patch, so CI testing i= s not very valuable." On the other hand, I'm sure in > > many cases getting that early feedback, even for an RFC, is helpful to = developers. I'll bring it up in the CI testing > > meeting tomorrow and see if any of the CI testing people have an opinio= n. Anyways, I think all labs should have the > > same policy, be it testing or not testing on RFC patches. > > We do currently skip running RFCs as well. IIRC they were eating into > our timing budget on Travis, and we never bothered to re-evaluate after > the switch to github actions. I think it would be good to discuss it. I once missed some issues in a RFC of mine that I only discovered when sending the first non-RFC patch. As far as time budget is concerned now, I don't think testing RFC is that much of an issue. We have way more people sending 3-4 revisions in a single day than people sending RFCs :-). --=20 David Marchand