* Re: [dpdk-ci] [dpdk-dev] DPDK Release Status Meeting 20/05/2021
[not found] <YKZSyX8NJuMZ4fY5@silpixa00399752>
@ 2021-05-20 12:51 ` Ferruh Yigit
2021-05-20 19:19 ` Aaron Conole
0 siblings, 1 reply; 7+ messages in thread
From: Ferruh Yigit @ 2021-05-20 12:51 UTC (permalink / raw)
To: Aaron Conole; +Cc: ci
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?
Thanks,
ferruh
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-ci] [dpdk-dev] DPDK Release Status Meeting 20/05/2021
2021-05-20 12:51 ` [dpdk-ci] [dpdk-dev] DPDK Release Status Meeting 20/05/2021 Ferruh Yigit
@ 2021-05-20 19:19 ` Aaron Conole
2021-05-24 12:02 ` Ferruh Yigit
0 siblings, 1 reply; 7+ messages in thread
From: Aaron Conole @ 2021-05-20 19:19 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: ci
Ferruh Yigit <ferruh.yigit@intel.com> 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.
> Thanks,
> ferruh
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-ci] [dpdk-dev] DPDK Release Status Meeting 20/05/2021
2021-05-20 19:19 ` Aaron Conole
@ 2021-05-24 12:02 ` Ferruh Yigit
2021-05-24 12:13 ` Ali Alnubani
0 siblings, 1 reply; 7+ messages in thread
From: Ferruh Yigit @ 2021-05-24 12:02 UTC (permalink / raw)
To: Aaron Conole; +Cc: ci
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}
>>> =====================================
>>> :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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-ci] [dpdk-dev] DPDK Release Status Meeting 20/05/2021
2021-05-24 12:02 ` Ferruh Yigit
@ 2021-05-24 12:13 ` Ali Alnubani
2021-05-24 16:11 ` Ferruh Yigit
0 siblings, 1 reply; 7+ messages in thread
From: Ali Alnubani @ 2021-05-24 12:13 UTC (permalink / raw)
To: Ferruh Yigit, Aaron Conole; +Cc: ci
> -----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/05/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}
> >>> =====================================
> >>> :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?
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-ci] [dpdk-dev] DPDK Release Status Meeting 20/05/2021
2021-05-24 12:13 ` Ali Alnubani
@ 2021-05-24 16:11 ` Ferruh Yigit
2021-06-17 14:43 ` Lincoln Lavoie
0 siblings, 1 reply; 7+ messages in thread
From: Ferruh Yigit @ 2021-05-24 16:11 UTC (permalink / raw)
To: Ali Alnubani, Aaron Conole; +Cc: ci
On 5/24/2021 1:13 PM, Ali Alnubani wrote:
>> -----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/05/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}
>>>>> =====================================
>>>>> :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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-ci] [dpdk-dev] DPDK Release Status Meeting 20/05/2021
2021-05-24 16:11 ` Ferruh Yigit
@ 2021-06-17 14:43 ` Lincoln Lavoie
2021-06-17 17:06 ` Ali Alnubani
0 siblings, 1 reply; 7+ messages in thread
From: Lincoln Lavoie @ 2021-06-17 14:43 UTC (permalink / raw)
To: Ali Alnubani; +Cc: Aaron Conole, Ferruh Yigit, ci
[-- Attachment #1: Type: text/plain, Size: 3882 bytes --]
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 <ferruh.yigit@intel.com>
wrote:
> On 5/24/2021 1:13 PM, Ali Alnubani wrote:
> >> -----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/05/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}
> >>>>> =====================================
> >>>>> :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)
<https://www.iol.unh.edu>
[-- Attachment #2: Type: text/html, Size: 6497 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-ci] [dpdk-dev] DPDK Release Status Meeting 20/05/2021
2021-06-17 14:43 ` Lincoln Lavoie
@ 2021-06-17 17:06 ` Ali Alnubani
0 siblings, 0 replies; 7+ messages in thread
From: Ali Alnubani @ 2021-06-17 17:06 UTC (permalink / raw)
To: Lincoln Lavoie; +Cc: Aaron Conole, Ferruh Yigit, ci
[-- Attachment #1: Type: text/plain, Size: 4464 bytes --]
I see, thanks Lincoln.
Regards,
Ali
From: Lincoln Lavoie <lylavoie@iol.unh.edu>
Sent: Thursday, June 17, 2021 5:44 PM
To: Ali Alnubani <alialnu@nvidia.com>
Cc: Aaron Conole <aconole@redhat.com>; Ferruh Yigit <ferruh.yigit@intel.com>; ci@dpdk.org
Subject: Re: [dpdk-ci] [dpdk-dev] DPDK Release Status Meeting 20/05/2021
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 <ferruh.yigit@intel.com<mailto:ferruh.yigit@intel.com>> wrote:
On 5/24/2021 1:13 PM, Ali Alnubani wrote:
>> -----Original Message-----
>> From: ci <ci-bounces@dpdk.org<mailto:ci-bounces@dpdk.org>> On Behalf Of Ferruh Yigit
>> Sent: Monday, May 24, 2021 3:02 PM
>> To: Aaron Conole <aconole@redhat.com<mailto:aconole@redhat.com>>
>> Cc: ci@dpdk.org<mailto: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 <ferruh.yigit@intel.com<mailto:ferruh.yigit@intel.com>> 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<mailto: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<mailto:lylavoie@iol.unh.edu>
https://www.iol.unh.edu
+1-603-674-2755 (m)
[https://docs.google.com/uc?export=download&id=1j_iI6anwrnbQWNpTyuvukMLSNJJ8_8QU&revid=0B_0ujwABDnFZTmJiR3EzK0d1VjFKTjQvMENBWVM0QnA4ajhjPQ]<https://www.iol.unh.edu/>
[-- Attachment #2: Type: text/html, Size: 9824 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-06-17 17:06 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <YKZSyX8NJuMZ4fY5@silpixa00399752>
2021-05-20 12:51 ` [dpdk-ci] [dpdk-dev] DPDK Release Status Meeting 20/05/2021 Ferruh Yigit
2021-05-20 19:19 ` Aaron Conole
2021-05-24 12:02 ` Ferruh Yigit
2021-05-24 12:13 ` Ali Alnubani
2021-05-24 16:11 ` Ferruh Yigit
2021-06-17 14:43 ` Lincoln Lavoie
2021-06-17 17:06 ` Ali Alnubani
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).