Hi,
in the following review: https://bugzilla.redhat.com/show_bug.cgi?id=1285042 a package was reviewed and approved under the name "kpmcore", which matches how upstream calls its tarballs. However, the subject line incorrectly spelled the name as "KPMcore" in camel-case, which was not caught during review, and so when the package was created in pkgdb, the submitter accidentally requested the module as "KPMcore". Unfortunately, the automated checks apparently do not notice mismatches between the specfile name and the subject line, and neither did the reviewer.
In addition, since nobody reviewed that rename, it also does not handle Provides correctly, there isn't even a Provides for the correct name.
So I would like to ask: * How can this particular package get fixed? I sure hope the answer is not to stick to the incorrect camel-case name forever! Can the administrators please look into this? * Can we add some additional sanity checks to prevent this from happening again in the future? I guess the issue there is that specfile links do not necessarily contain the file name in the link or even contain it, they can be fpaste links, links into some SCM viewer, etc. We would also need to check the latest specfile link, not the first, because sometimes, package names are fixed as part of the review process. But if we can find a solution that does not break current use cases, I think it would be very helpful.
Kevin Kofler
2016-01-16 16:10 GMT+01:00 Kevin Kofler kevin.kofler@chello.at:
Hi,
in the following review: https://bugzilla.redhat.com/show_bug.cgi?id=1285042 a package was reviewed and approved under the name "kpmcore", which matches how upstream calls its tarballs. However, the subject line incorrectly spelled the name as "KPMcore" in camel-case, which was not caught during review, and so when the package was created in pkgdb, the submitter accidentally requested the module as "KPMcore". Unfortunately, the automated checks apparently do not notice mismatches between the specfile name and the subject line, and neither did the reviewer.
In addition, since nobody reviewed that rename, it also does not handle Provides correctly, there isn't even a Provides for the correct name.
So I would like to ask:
- How can this particular package get fixed? I sure hope the answer is not to stick to the incorrect camel-case name forever! Can the administrators please look into this?
Since this package only hit rawhide, I guess we can accept that releng fixes the repo and avoid the rename process. http://koji.fedoraproject.org/koji/packageinfo?packageID=21440
If it were a stable or branched release, I would insist to follow the rename process.
Can we add some additional sanity checks to prevent this from happening again in the future? I guess the issue there is that specfile links do not necessarily contain the file name in the link or even contain it, they can be fpaste links, links into some SCM viewer, etc. We would also need to check the latest specfile link, not the first, because sometimes, package names are fixed as part of the review process. But if we can find a solution that does not break current use cases, I think it would be very helpful.
Kevin Kofler
That is an excellent idea, I encourage you to open a ticket in pkgdb2.
I guess we could add sanity check to the bugzilla sync script https://github.com/fedora-infra/pkgdb2/blob/0b40ed5e7543a587b0acc8118f0f99ca...
It could be either a flash message warning packager or plainly refuses to create the request if you don't fix the ticket.
Regards, H.
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On Sat, Jan 16, 2016 at 05:43:19PM +0100, Haïkel wrote:
2016-01-16 16:10 GMT+01:00 Kevin Kofler kevin.kofler@chello.at:
Hi,
in the following review: https://bugzilla.redhat.com/show_bug.cgi?id=1285042 a package was reviewed and approved under the name "kpmcore", which matches how upstream calls its tarballs. However, the subject line incorrectly spelled the name as "KPMcore" in camel-case, which was not caught during review, and so when the package was created in pkgdb, the submitter accidentally requested the module as "KPMcore". Unfortunately, the automated checks apparently do not notice mismatches between the specfile name and the subject line, and neither did the reviewer.
In addition, since nobody reviewed that rename, it also does not handle Provides correctly, there isn't even a Provides for the correct name.
So I would like to ask:
- How can this particular package get fixed? I sure hope the answer is not to stick to the incorrect camel-case name forever! Can the administrators please look into this?
Since this package only hit rawhide, I guess we can accept that releng fixes the repo and avoid the rename process. http://koji.fedoraproject.org/koji/packageinfo?packageID=21440
If it were a stable or branched release, I would insist to follow the rename process.
The easiest might be to open a ticket on either the rel-eng trac or the infra one.
- Can we add some additional sanity checks to prevent this from happening again in the future? I guess the issue there is that specfile links do not necessarily contain the file name in the link or even contain it, they can be fpaste links, links into some SCM viewer, etc. We would also need to check the latest specfile link, not the first, because sometimes, package names are fixed as part of the review process. But if we can find a solution that does not break current use cases, I think it would be very helpful.
That is an excellent idea, I encourage you to open a ticket in pkgdb2.
There are two projects involved here: - pkgdb2 when the package request is created, this one does some basic checks in: https://github.com/fedora-infra/pkgdb2/blob/master/pkgdb2/api/extras.py - packagedb-cli which ships pkgdb-admin ran by the rel-eng people to process these requests. This one does some more thorough checks and would have my preference as the place to fix this (since it would have to parse all the comments from the review to find the spec file and try to extract a name).
Pierre
Il 16/01/2016 17:43, Haïkel ha scritto:
Since this package only hit rawhide, I guess we can accept that releng fixes the repo and avoid the rename process. http://koji.fedoraproject.org/koji/packageinfo?packageID=21440
If it were a stable or branched release, I would insist to follow the rename process.
I have already opened a review request for renaming package:
kpmcore is now built in Rawhide.
Can I move ahead and retire KPMcore or should I wait some time before doing that?