From Fedora Project Wiki
No edit summary |
m (Minor template fix to get backreference to work) |
||
| (4 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{Summer of Code Idea|AutoQA | {{Summer of Code Idea|AutoQA detect false positives|IDEA|||python, searching best solutions, working with big data-sets | ||
| Generally this task would be about going through all the false positives AutoQA reported and figuring a method how not to run into the issue again and how to detect, if something changes. AutoQA needs to filter out this issues and not report them. | | Generally this task would be about going through all the false positives AutoQA reported and figuring a method how not to run into the issue again and how to detect, if something changes. AutoQA needs to filter out this issues and not report them. | ||
}} | }} | ||
| Line 6: | Line 6: | ||
* https://fedorahosted.org/pipermail/autoqa-results/2010-April/013933.html | * https://fedorahosted.org/pipermail/autoqa-results/2010-April/013933.html | ||
** add some black/white-list | ** add some black/white-list | ||
** "explicit-lib-dependency liberation-mono-fonts" thinks that liberation-mono-fonts is a library, but it is IMO OK to depend on the specific font | |||
* https://fedorahosted.org/pipermail/autoqa-results/2010-April/013903.html | * https://fedorahosted.org/pipermail/autoqa-results/2010-April/013903.html | ||
** see the "libgnome" issue - somebody could add names of all packages and their's files into the dictionary | ** see the "libgnome" issue - somebody could add names of all packages and their's files into the dictionary | ||
| Line 11: | Line 12: | ||
* https://fedorahosted.org/pipermail/autoqa-results/2010-April/013908.html | * https://fedorahosted.org/pipermail/autoqa-results/2010-April/013908.html | ||
** migth ignore conflicts like this - like if I have conflicting basepackage-subpackage1-ver1 and basepackage-subpackage2-ver2 - I can determine, that the conflict is only theoretical, because if I have updated system, there will be only one of the packages. | ** migth ignore conflicts like this - like if I have conflicting basepackage-subpackage1-ver1 and basepackage-subpackage2-ver2 - I can determine, that the conflict is only theoretical, because if I have updated system, there will be only one of the packages. | ||
* https://fedorahosted.org/pipermail/autoqa-results/2010-April/013919.html | |||
** I do not know exactly what is the purpose of the test as the conflicts are valid properties of the rpm. On the other hand, file conflicts are bad. But take a look at the items found. It looks like there are just files moved from one sub-package to the another, like this (check different versions): `libmlx4-devel-1.0-4.fc12.x86_64 libmlx4-static-1.0.1-5.fc12.x86_64 /usr/lib64/libmlx4.a` or sub-package were renamed: `openscada-Special-FLibSYS-0.6.4.1-9.fc12.x86_64 openscada-Special-FlibSys-0.6.4-4.fc12.x86_64 /usr/lib64/openscada/spec_FLibSYS.so` | |||
* ...and more. | * ...and more. | ||
</noinclude> | </noinclude> | ||
Latest revision as of 11:56, 28 April 2010
AutoQA detect false positives
| Status | Contact | Mentor | Skills |
|---|---|---|---|
| IDEA | nobody | nobody | python, searching best solutions, working with big data-sets |
| Description | |||
| Generally this task would be about going through all the false positives AutoQA reported and figuring a method how not to run into the issue again and how to detect, if something changes. AutoQA needs to filter out this issues and not report them. | |||
Take a look at these issues (for example):
- https://fedorahosted.org/pipermail/autoqa-results/2010-April/013933.html
- add some black/white-list
- "explicit-lib-dependency liberation-mono-fonts" thinks that liberation-mono-fonts is a library, but it is IMO OK to depend on the specific font
- https://fedorahosted.org/pipermail/autoqa-results/2010-April/013903.html
- see the "libgnome" issue - somebody could add names of all packages and their's files into the dictionary
- problem "doc-file-dependency /usr/share/doc/gnome-python2-gnomevfs-2.28.1/async-xfer.py /usr/bin/env" could be reported directly as a bug. Could some Python-guy confirm that "/usr/bin/env python" was obsoleted by "/usr/bin/python"?
- https://fedorahosted.org/pipermail/autoqa-results/2010-April/013908.html
- migth ignore conflicts like this - like if I have conflicting basepackage-subpackage1-ver1 and basepackage-subpackage2-ver2 - I can determine, that the conflict is only theoretical, because if I have updated system, there will be only one of the packages.
- https://fedorahosted.org/pipermail/autoqa-results/2010-April/013919.html
- I do not know exactly what is the purpose of the test as the conflicts are valid properties of the rpm. On the other hand, file conflicts are bad. But take a look at the items found. It looks like there are just files moved from one sub-package to the another, like this (check different versions):
libmlx4-devel-1.0-4.fc12.x86_64 libmlx4-static-1.0.1-5.fc12.x86_64 /usr/lib64/libmlx4.aor sub-package were renamed:openscada-Special-FLibSYS-0.6.4.1-9.fc12.x86_64 openscada-Special-FlibSys-0.6.4-4.fc12.x86_64 /usr/lib64/openscada/spec_FLibSYS.so
- I do not know exactly what is the purpose of the test as the conflicts are valid properties of the rpm. On the other hand, file conflicts are bad. But take a look at the items found. It looks like there are just files moved from one sub-package to the another, like this (check different versions):
- ...and more.