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 3FD7FA0547 for ; Mon, 24 May 2021 14:02:19 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 372634003E; Mon, 24 May 2021 14:02:19 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id 1593D4003C for ; Mon, 24 May 2021 14:02:16 +0200 (CEST) IronPort-SDR: hgw91A3Z200mfgeuKiD+IcClA9bzwx8Xk9X2FEWwY9eNbCXj/HaeXyEJJD4d8d+WFJkRHalmt2 w5IC13aKK0CQ== X-IronPort-AV: E=McAfee;i="6200,9189,9993"; a="198859989" X-IronPort-AV: E=Sophos;i="5.82,319,1613462400"; d="scan'208";a="198859989" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 May 2021 05:02:15 -0700 IronPort-SDR: 5eQcJs8UUhLW67kAK9uOmGlYQxokNPq8sFJa/v9xn9XUEzH9eAzodibk0QJmHz8avgYT6qct34 LL9ybkQeGGPA== X-IronPort-AV: E=Sophos;i="5.82,319,1613462400"; d="scan'208";a="546319491" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.210.125]) ([10.213.210.125]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 May 2021 05:02:14 -0700 To: Aaron Conole Cc: "ci@dpdk.org" References: <9628dbc9-9fcc-6a1a-d389-75896ad2f392@intel.com> From: Ferruh Yigit X-User: ferruhy Message-ID: Date: Mon, 24 May 2021 13:02:10 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-ci] [dpdk-dev] DPDK Release Status Meeting 20/05/2021 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 Sender: "ci" On 5/20/2021 8:19 PM, Aaron Conole wrote: > Ferruh Yigit writes: > >> On 5/20/2021 1:15 PM, Ferruh Yigit wrote: >>> Release status meeting minutes {Date} >>> ===================================== >>> :Date: 20 May 2021 >>> :toc: >> >> <...> >> >>> * Coverity is running regularly >>> - Can we have out of cycle run for -rc4? Last run was yesterday. >>> - We need a way to verify coverity issues before merging it, will carry topic >>> to CI mail list an Aaron >> >> Hi Aaron, >> >> There is a need to verify coverity fixes before merging them. Do you think can >> we do that? And should I create a Bugzilla ticket for it? > > I think you can create a BZ for it. Last I remember, coverity does not > allow so many frequent builds (without paying?), so there is probably a > non-technical limitation. Otherwise, we could simply submit all patch > series to coverity and look at the results. > > As it stands, there is maybe more thought that has to come with this. > > Maybe we can use a tag that indicates which coverity ID it purports to > fix, and we can then kick off a run. > Yes, we can only run coverity with the patches that has coverity tag. Do we know the limitation on the run? Even if we can run once a day I think it can be enough, coverity already not running daily, in the gap days coverity patches can be verified. Also we can skip coverity run if the main branch is not updated since last check, this can gain some runs too. Created following Bugzilla: https://bugs.dpdk.org/show_bug.cgi?id=719 btw, Aaron I didn't able to cc your Red Hat email but found following, can you confirm it is your email address: aconole@bytheb.org