On Tue, Jul 9, 2024 at 2:28 PM Richard W.M. Jones <rjones@xxxxxxxxxx> wrote:
On Tue, Jul 09, 2024 at 01:37:20PM +0200, Siteshwar Vashisht wrote:
> I request somebody from the tools team to comment on these concerns. We only
> report the defects identified by gcc, clang etc.
You wrote:
> TLDR: This report[2] contains 73976 identified defects.
and again above said they were "defects". Well, we know the ones in
libvirt & QEMU are nearly all NOT defects, so don't use that word.
> Please review the report and provide feedback.
At 1 minute to look at each report, working 8 hours a day, that would
take 154 working days.
FAS usernames of the package owners are listed in the report. So my request was pointed towards the people who maintain those packages. I did not ask each maintainer to review each defect. Sorry, if my request was not clear.
Constructively I would suggest YOU doing the following:
(1) Examine a subset of the reports yourself.
(2) Identity systematic issues, such as the attribute((cleanup)) issue
that Dan pointed out, and work with the upstream toolchain to get
those fixed (apparently the attribute((cleanup)) issue is / will be
fixed already, so that's good).
I maintain a very limited set of packages in Fedora and I am not familiar with the code in other packages. Therefore, I have to request for reviews from respective package maintainers. It is up to the respective package maintainers to identify false positives. However, I agree that we should make it easier to do so in our tooling. We are at the beginning stage of performing mass scans in Fedora, so some packages may have a higher rate of having false positives than others.
(3) If during this search you find what you think is an actual defect,
file a bug with the upstream package.
Ideally, this step should be performed by the respective package maintainers. It is easy to misidentify a possible defect when a person is not familiar with the code.
(4) Repeat steps (1)..(3) until the list is much, much smaller.
We are performing differential scans on each listed package with Fedora 40 versions. So, if a maintainer does not have time to go through the full report, they can at least look at the differential scan report. For example, the package `supermin` has no new possible defects identified through differential scans between `supermin-5.3.4-4.fc41` and `supermin-5.3.4-2.fc40`.
Thanks for the feedback! But I believe it's very subjective due to the high rate of false positives in packages your team maintains. The goal of performing mass scans is to give visibility to the usefulness of this service, specially for legacy codebases.
Having said that, I agree that we may need to do a better job in communication. Thank you!
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
