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 3D671A0C4B for ; Thu, 17 Jun 2021 16:43:50 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E6A3F4067A; Thu, 17 Jun 2021 16:43:49 +0200 (CEST) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by mails.dpdk.org (Postfix) with ESMTP id BA2A440150 for ; Thu, 17 Jun 2021 16:43:48 +0200 (CEST) Received: by mail-ed1-f46.google.com with SMTP id t3so4363973edc.7 for ; Thu, 17 Jun 2021 07:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mmJEnElEktcxyLn4aFyVcskTdnJ2WTnYc5qG+WW8Vhs=; b=KzMfey4qoyRGWyGqEPEpjGQ46vADxI/8GVUEklGalljlPWcTbU3+Y6xUbT8P1VrBqL 60dMIiVGwkcs4BhBMUhr3hOCqhQlrZef+Z1dQ/4WEb61qtEZhKwPVpw4zYIwks0EDk9E XbG/5KsNh89MLIu6dWEjcVZd6zOtPBrvKQNCM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mmJEnElEktcxyLn4aFyVcskTdnJ2WTnYc5qG+WW8Vhs=; b=WF9MVreuyw3B6woQkTGMI98WdhQ4v5dH56mr4hkc2FnVmOxPKEaPF/AZyCvBeDkWUR jNIXfcbJ1BQzUEb78PT0b+gxLHf3ROB878jW0D4JPaMJR8SKDzQDq/Zwbg4EswcU0TRn TvWNEQ8h9DOReYRFdEryUEGMXDZT2J4h5TRBz8R/1TMa2dRtuUmwoRBBnK3i41HA3Pp9 yzFyYCeErmeI6x7nW8k0UCVXUQmUGQKUKZpaMT6muRDLzk30xM1A+FhKPseejpfH6XuT ljZlW0zvSGg2jFVp+7HQZnzB1hOz4TvJEYra8o6EycEf38RgJd30ZYXPeqFTqseb5/ot N5uA== X-Gm-Message-State: AOAM530JHtTT+4HqUjrjpURMQACY6CFX+2HaiCfGGZpjlqmJxpw7tPOK 4j8dcz7i6hZGS9+LwzDzGo9u7ETOCl6oS3ceJ917+A== X-Google-Smtp-Source: ABdhPJzDA2C/JZgHJUgb5uqXysHOLda2zXAyf9eimbu41xYEjf54o6nSYIXKBBYvkQjo2aaZLMYU8I+T8F5657nFMrU= X-Received: by 2002:a05:6402:1508:: with SMTP id f8mr3833038edw.172.1623941028401; Thu, 17 Jun 2021 07:43:48 -0700 (PDT) MIME-Version: 1.0 References: <9628dbc9-9fcc-6a1a-d389-75896ad2f392@intel.com> In-Reply-To: From: Lincoln Lavoie Date: Thu, 17 Jun 2021 10:43:37 -0400 Message-ID: To: Ali Alnubani Cc: Aaron Conole , Ferruh Yigit , "ci@dpdk.org" Content-Type: multipart/alternative; boundary="0000000000002266d005c4f73cbc" 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" --0000000000002266d005c4f73cbc Content-Type: text/plain; charset="UTF-8" Hi Ali, >From what I can tell, the Coverity Desktop analysis tools would require paid licenses, which are different from the Coverity Scan ( https://scan.coverity.com/faq) that is being used by DPDK as an open source project. So, to enable using the tooling to scan all the patches, we'd need to work out the requirements around getting access to the other Synopsys tools. Cheers, Lincoln On Mon, May 24, 2021 at 12:13 PM Ferruh Yigit wrote: > 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 > > > > -- *Lincoln Lavoie* Principal Engineer, Broadband Technologies 21 Madbury Rd., Ste. 100, Durham, NH 03824 lylavoie@iol.unh.edu https://www.iol.unh.edu +1-603-674-2755 (m) --0000000000002266d005c4f73cbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi = Ali,

=
From what I can tell= , the Coverity Desktop analysis tools would require paid licenses, which ar= e different from the Coverity Scan (https://scan.coverity.com/faq) that is being used by DPDK as an open= source project.=C2=A0=C2=A0

So, to enable using the tooling to scan all the patches, we'd need = to work out the requirements=C2=A0around getting access to the other Synops= ys tools.

<= /div>
Cheers,
Linc= oln

<= /div>
O= n Mon, May 24, 2021 at 12:13 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
On 5/24/2021 1:13 PM, Ali Alnubani wr= ote:
>> -----Original Message-----
>> From: ci <ci-bounces@dpdk.org> On Behalf Of Ferruh Yigit
>> Sent: Monday, May 24, 2021 3:02 PM
>> To: Aaron Conole <aconole@redhat.com>
>> Cc: ci@dpdk.org
>> Subject: Re: [dpdk-ci] [dpdk-dev] DPDK Release Status Meeting 20/0= 5/2021
>>
>> On 5/20/2021 8:19 PM, Aaron Conole wrote:
>>> Ferruh Yigit <ferruh.yigit@intel.com> writes:
>>>
>>>> On 5/20/2021 1:15 PM, Ferruh Yigit wrote:
>>>>> Release status meeting minutes {Date}
>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>> :Date: 20 May 2021
>>>>> :toc:
>>>>
>>>> <...>
>>>>
>>>>> * Coverity is running regularly
>>>>>=C2=A0 =C2=A0- Can we have out of cycle run for -rc4? L= ast run was yesterday.
>>>>>=C2=A0 =C2=A0- We need a way to verify coverity issues = before merging it, will carry
>> topic
>>>>>=C2=A0 =C2=A0 =C2=A0to CI mail list an Aaron
>>>>
>>>> Hi Aaron,
>>>>
>>>> There is a need to verify coverity fixes before merging th= em. Do you
>>>> think can we do that? And should I create a Bugzilla ticke= t for it?
>>>
>>> I think you can create a BZ for it.=C2=A0 Last I remember, cov= erity does
>>> not allow so many frequent builds (without paying?), so there = is
>>> probably a non-technical limitation.=C2=A0 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 wit= h this.
>>>
>>> Maybe we can use a tag that indicates which coverity ID it pur= ports to
>>> fix, and we can then kick off a run.
>>>
>>
>> Yes, we can only run coverity with the patches that has coverity t= ag.
>>
>> Do we know the limitation on the run? Even if we can run once a da= y 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 si= nce last
>> check, this can gain some runs too.
>>
>> Created following Bugzilla:
>> https://bugs.dpdk.org/show_bug.cgi?id=3D719<= br> >>
>> btw, Aaron I didn't able to cc your Red Hat email but found fo= llowing, can you
>> confirm it is your email address:
>> aconole@by= theb.org
>
> It should also be possible to run Coverity's cov-run-desktop binar= y to make sure a patchset doesn't introduce new defects in the first pl= ace. 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 coverit= y
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 fu= ll 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
>



--
Lincoln Lavoie
Prin= cipal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, = Durham, NH 03824
+1-603-674-= 2755 (m)

--0000000000002266d005c4f73cbc--