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 477CFA0547 for ; Mon, 24 May 2021 18:13:39 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 388084003E; Mon, 24 May 2021 18:13:39 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 2E8224003C for ; Mon, 24 May 2021 18:13:37 +0200 (CEST) IronPort-SDR: OjAbof54PAwImbGO2Aoke0jR3f/Q/g/vnZoOxQXk4dE0d5ok7+HCK+uUUCg9vwY0L05G62KAs8 botpQaMAerTA== X-IronPort-AV: E=McAfee;i="6200,9189,9993"; a="223124986" X-IronPort-AV: E=Sophos;i="5.82,325,1613462400"; d="scan'208";a="223124986" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 May 2021 09:11:31 -0700 IronPort-SDR: fYLfyU5ZoSEbJdK0pwp3GziHh7mDttnJs0LuT29ZvHbbgJ4hgrL/5R2X98Qlfyi3wnkapB4aP8 vJRK9+KI5W6g== X-IronPort-AV: E=Sophos;i="5.82,325,1613462400"; d="scan'208";a="546411018" 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 09:11:29 -0700 To: Ali Alnubani , 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 17:11:26 +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/24/2021 1:13 PM, Ali Alnubani wrote: >> -----Original Message----- >> From: ci On Behalf Of Ferruh Yigit >> Sent: Monday, May 24, 2021 3:02 PM >> To: Aaron Conole >> Cc: ci@dpdk.org >> Subject: Re: [dpdk-ci] [dpdk-dev] DPDK Release Status Meeting 20/05/2021 >> >> 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 > > It should also be possible to run Coverity's cov-run-desktop binary to make sure a patchset doesn't introduce new defects in the first place. Is there a reason why we don't do this already? If there is a way for developer to verify it easily, it is even better. In the version of coverity I run, user is building project with the coverity toolset and uploading the resulting binaries to the coverity server, which scans and makes result available via web interface. This way user can't validate the patch in the client, but if there is a way for it we can try that too. > The binary scans only the modified files and compares to the latest full scan to check how many new defects there are. > The binary can run on UNH's servers so I don't think it would be limited. Are we maybe limited by how many times we can pull the summary/data of the latest scan? We can pull it only once a day and use it offline mode. > > Regards, > Ali >