Hello everyone,
The New Hotness 1.0.0 is now live in Fedora infra production environment. For those who don't know what this app does, it basically notifying packagers about new versions of packages by creating bugzilla issues.
And what is new: * The New Hotness was rewritten from scratch using clean architecture design (it's now easier to maintain and less error prone) * Documentation[0] was updated to be more useful and up to date * The comments created in bugzilla should be more helpful and contain info about errors if any happens during the scratch build * The New Hotness now remembers the Koji Task ID,even if there is error in post scratch build. In past the task ID was just lost and when the build was finished The New Hotness couldn't recognize it * We now have a containerized workflow for development
If you want to look at full changelog, please visit the-new-hotness GitHub release page [1].
Thanks to everybody who contributed to this release!
Regards, Michal Mage from release-monitoring.org
[0] - https://the-new-hotness.readthedocs.io/en/stable/ [1] - https://github.com/fedora-infra/the-new-hotness/releases/tag/1.0.0
On 09. 12. 21 13:54, Michal Konecny wrote:
Hello everyone,
The New Hotness 1.0.0 is now live in Fedora infra production environment. For those who don't know what this app does, it basically notifying packagers about new versions of packages by creating bugzilla issues.
And what is new:
- The New Hotness was rewritten from scratch using clean architecture design
(it's now easier to maintain and less error prone)
- Documentation[0] was updated to be more useful and up to date
- The comments created in bugzilla should be more helpful and contain info
about errors if any happens during the scratch build
- The New Hotness now remembers the Koji Task ID,even if there is error in post
scratch build. In past the task ID was just lost and when the build was finished The New Hotness couldn't recognize it
- We now have a containerized workflow for development
If you want to look at full changelog, please visit the-new-hotness GitHub release page [1].
Awesome!
Let me use this as an opportunity to ask: How can I disable reporting of pre-releases?
On Thu, Dec 9 2021 at 02:25:11 PM +0100, Miro Hrončok mhroncok@redhat.com wrote:
Let me use this as an opportunity to ask: How can I disable reporting of pre-releases?
I have the opposite question. Previously, once a pre-release tarball was available, the new hotness would stop reporting when a new stable tarball becomes available. Is that fixed?
On 09. 12. 21 15:20, Michael Catanzaro wrote:
On Thu, Dec 9 2021 at 02:25:11 PM +0100, Miro Hrončok mhroncok@redhat.com wrote:
Let me use this as an opportunity to ask: How can I disable reporting of pre-releases?
I have the opposite question. Previously, once a pre-release tarball was available, the new hotness would stop reporting when a new stable tarball becomes available. Is that fixed?
The New Hotness uses RPM version comparison for this and if this fails, there isn't much we can do about it. See https://github.com/fedora-infra/the-new-hotness/blob/2b3f7d7c2af847a48d190ca... if you want to look at how the compare method is implemented.
We still want to only report versions that are considered newer by RPM comparison method.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Dec 9, 2021 at 8:32 AM Michal Konecny mkonecny@redhat.com wrote:
The New Hotness uses RPM version comparison for this and if this fails, there isn't much we can do about it. See https://github.com/fedora-infra/the-new-hotness/blob/2b3f7d7c2af847a48d190ca... if you want to look at how the compare method is implemented.
We still want to only report versions that are considered newer by RPM comparison method.
How about reporting all versions that are newer than the package version in Rawhide, whether or not they are newer than other previously reported versions?
If you think this will be a fine feature for The New Hotness, please feel free to file a ticket in https://github.com/fedora-infra/the-new-hotness/issues
Michal
On 09. 12. 21 16:49, Jerry James wrote:
On Thu, Dec 9, 2021 at 8:32 AM Michal Konecny mkonecny@redhat.com wrote:
The New Hotness uses RPM version comparison for this and if this fails, there isn't much we can do about it. See https://github.com/fedora-infra/the-new-hotness/blob/2b3f7d7c2af847a48d190ca... if you want to look at how the compare method is implemented.
We still want to only report versions that are considered newer by RPM comparison method.
How about reporting all versions that are newer than the package version in Rawhide, whether or not they are newer than other previously reported versions?
On Thu, Dec 9 2021 at 03:59:39 PM +0100, Michal Konecny mkonecny@redhat.com wrote:
The New Hotness uses RPM version comparison for this and if this fails, there isn't much we can do about it. See https://github.com/fedora-infra/the-new-hotness/blob/2b3f7d7c2af847a48d190ca... if you want to look at how the compare method is implemented.
What's sad is that release-monitoring.org knows exactly which release is prerelease and which release is stable, so it's a shame that info gets lost somewhere before it manages to report a bug. Bug reports are nice, but some other mechanism for release notifications that doesn't lose the release information would be even better....
Michael
The information is not lost (it's already emitted by Anitya in anitya.project.version.update.v2 message topic), The New Hotness just don't know how to work with it yet. It's planned as an upcoming feature.
Michal
On 09. 12. 21 16:54, Michael Catanzaro wrote:
On Thu, Dec 9 2021 at 03:59:39 PM +0100, Michal Konecny mkonecny@redhat.com wrote:
The New Hotness uses RPM version comparison for this and if this fails, there isn't much we can do about it. See https://github.com/fedora-infra/the-new-hotness/blob/2b3f7d7c2af847a48d190ca...
if you want to look at how the compare method is implemented.
What's sad is that release-monitoring.org knows exactly which release is prerelease and which release is stable, so it's a shame that info gets lost somewhere before it manages to report a bug. Bug reports are nice, but some other mechanism for release notifications that doesn't lose the release information would be even better....
Michael
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 09. 12. 21 14:25, Miro Hrončok wrote:
On 09. 12. 21 13:54, Michal Konecny wrote:
Hello everyone,
The New Hotness 1.0.0 is now live in Fedora infra production environment. For those who don't know what this app does, it basically notifying packagers about new versions of packages by creating bugzilla issues.
And what is new:
- The New Hotness was rewritten from scratch using clean architecture
design (it's now easier to maintain and less error prone)
- Documentation[0] was updated to be more useful and up to date
- The comments created in bugzilla should be more helpful and contain
info about errors if any happens during the scratch build
- The New Hotness now remembers the Koji Task ID,even if there is
error in post scratch build. In past the task ID was just lost and when the build was finished The New Hotness couldn't recognize it
- We now have a containerized workflow for development
If you want to look at full changelog, please visit the-new-hotness GitHub release page [1].
Awesome!
Let me use this as an opportunity to ask: How can I disable reporting of pre-releases?
Unfortunately, the only option now is to edit the project in Anitya to obtain only stable versions.
There will be option for it in The New Hotness in the future, but currently it can't recognize stable and pre-release version from each other.
On Thu, Dec 9, 2021 at 2:57 PM Miro Hrončok mhroncok@redhat.com wrote:
On 09. 12. 21 13:54, Michal Konecny wrote:
Hello everyone,
The New Hotness 1.0.0 is now live in Fedora infra production environment. For those who don't know what this app does, it basically notifying packagers about new versions of packages by creating bugzilla issues.
And what is new:
- The New Hotness was rewritten from scratch using clean architecture design
(it's now easier to maintain and less error prone)
- Documentation[0] was updated to be more useful and up to date
- The comments created in bugzilla should be more helpful and contain info
about errors if any happens during the scratch build
- The New Hotness now remembers the Koji Task ID,even if there is error in post
scratch build. In past the task ID was just lost and when the build was finished The New Hotness couldn't recognize it
- We now have a containerized workflow for development
If you want to look at full changelog, please visit the-new-hotness GitHub release page [1].
Awesome!
Let me use this as an opportunity to ask: How can I disable reporting of pre-releases?
The only way I can think of to "ignore" pre-releases is to add a "Version filter" on release-monitoring.org ... I've started adding a "alpha;beta;rc;pre" filter (and set the versioning to "semantic" to make sure they are sorted correctly) to all Rust packages I touch, because we don't package pre-releases except in rare circumstances.
Buuuut that only prevents anitya from fetching *new* pre-releases that match that filter, it doesn't remove those that are already in the database, and you won't get notifications for "new" versions that are "older" than the latest pre-release :(
Fabio
On 09. 12. 21 18:34, Fabio Valentini wrote:
On Thu, Dec 9, 2021 at 2:57 PM Miro Hrončok mhroncok@redhat.com wrote:
On 09. 12. 21 13:54, Michal Konecny wrote:
Hello everyone,
The New Hotness 1.0.0 is now live in Fedora infra production environment. For those who don't know what this app does, it basically notifying packagers about new versions of packages by creating bugzilla issues.
And what is new:
- The New Hotness was rewritten from scratch using clean architecture design
(it's now easier to maintain and less error prone)
- Documentation[0] was updated to be more useful and up to date
- The comments created in bugzilla should be more helpful and contain info
about errors if any happens during the scratch build
- The New Hotness now remembers the Koji Task ID,even if there is error in post
scratch build. In past the task ID was just lost and when the build was finished The New Hotness couldn't recognize it
- We now have a containerized workflow for development
If you want to look at full changelog, please visit the-new-hotness GitHub release page [1].
Awesome!
Let me use this as an opportunity to ask: How can I disable reporting of pre-releases?
The only way I can think of to "ignore" pre-releases is to add a "Version filter" on release-monitoring.org ... I've started adding a "alpha;beta;rc;pre" filter (and set the versioning to "semantic" to make sure they are sorted correctly) to all Rust packages I touch, because we don't package pre-releases except in rare circumstances.
Buuuut that only prevents anitya from fetching *new* pre-releases that match that filter, it doesn't remove those that are already in the database, and you won't get notifications for "new" versions that are "older" than the latest pre-release :(
Hopefully for Python packages, this should be fixed in the future with:
https://github.com/fedora-infra/anitya/pull/1175
Maybe it can be solved similarly for Rust packages?
On Thu, Dec 9, 2021 at 9:15 PM Miro Hrončok mhroncok@redhat.com wrote:
On 09. 12. 21 18:34, Fabio Valentini wrote:
On Thu, Dec 9, 2021 at 2:57 PM Miro Hrončok mhroncok@redhat.com wrote:
On 09. 12. 21 13:54, Michal Konecny wrote:
Hello everyone,
The New Hotness 1.0.0 is now live in Fedora infra production environment. For those who don't know what this app does, it basically notifying packagers about new versions of packages by creating bugzilla issues.
And what is new:
- The New Hotness was rewritten from scratch using clean architecture design
(it's now easier to maintain and less error prone)
- Documentation[0] was updated to be more useful and up to date
- The comments created in bugzilla should be more helpful and contain info
about errors if any happens during the scratch build
- The New Hotness now remembers the Koji Task ID,even if there is error in post
scratch build. In past the task ID was just lost and when the build was finished The New Hotness couldn't recognize it
- We now have a containerized workflow for development
If you want to look at full changelog, please visit the-new-hotness GitHub release page [1].
Awesome!
Let me use this as an opportunity to ask: How can I disable reporting of pre-releases?
The only way I can think of to "ignore" pre-releases is to add a "Version filter" on release-monitoring.org ... I've started adding a "alpha;beta;rc;pre" filter (and set the versioning to "semantic" to make sure they are sorted correctly) to all Rust packages I touch, because we don't package pre-releases except in rare circumstances.
Buuuut that only prevents anitya from fetching *new* pre-releases that match that filter, it doesn't remove those that are already in the database, and you won't get notifications for "new" versions that are "older" than the latest pre-release :(
Hopefully for Python packages, this should be fixed in the future with:
https://github.com/fedora-infra/anitya/pull/1175
Maybe it can be solved similarly for Rust packages?
Uhm ... not sure if I understand you correctly.
The "Semantic" versioning scheme support in anitya is working just fine for Rust crates. I just want to never get notified about pre-releases, because we *almost never* want to package those. And for that, I set the version filter.
Fabio
On 09. 12. 21 21:15, Miro Hrončok wrote:
On 09. 12. 21 18:34, Fabio Valentini wrote:
On Thu, Dec 9, 2021 at 2:57 PM Miro Hrončok mhroncok@redhat.com wrote:
On 09. 12. 21 13:54, Michal Konecny wrote:
Hello everyone,
The New Hotness 1.0.0 is now live in Fedora infra production environment. For those who don't know what this app does, it basically notifying packagers about new versions of packages by creating bugzilla issues.
And what is new:
- The New Hotness was rewritten from scratch using clean
architecture design (it's now easier to maintain and less error prone)
- Documentation[0] was updated to be more useful and up to date
- The comments created in bugzilla should be more helpful and
contain info about errors if any happens during the scratch build
- The New Hotness now remembers the Koji Task ID,even if there is
error in post scratch build. In past the task ID was just lost and when the build was finished The New Hotness couldn't recognize it
- We now have a containerized workflow for development
If you want to look at full changelog, please visit the-new-hotness GitHub release page [1].
Awesome!
Let me use this as an opportunity to ask: How can I disable reporting of pre-releases?
The only way I can think of to "ignore" pre-releases is to add a "Version filter" on release-monitoring.org ... I've started adding a "alpha;beta;rc;pre" filter (and set the versioning to "semantic" to make sure they are sorted correctly) to all Rust packages I touch, because we don't package pre-releases except in rare circumstances.
Buuuut that only prevents anitya from fetching *new* pre-releases that match that filter, it doesn't remove those that are already in the database, and you won't get notifications for "new" versions that are "older" than the latest pre-release :(
Hopefully for Python packages, this should be fixed in the future with:
https://github.com/fedora-infra/anitya/pull/1175
Maybe it can be solved similarly for Rust packages?
The New Hotness is still using RPM comparison for deciding if the version is newer than the old one regardless of how the versions are sorted in Anitya.
And in the future, The New Hotness will process all the new versions found by Anitya not only the newest one, this is why the anitya.project.version.update.v2 message topic was created. This is already prepared on Anitya side, but I still must implement it on The New Hotness side.
Michal
I honestly don't understand what the problem is. Why not simply notify whenever there is a new upstream tarball, regardless of what the version looks like? Trying to compare versions is pointless because we have as many as four different Fedora releases to maintain at any given time and they could all require updates from different upstream branches.
This would create a vast amount of bogus notifications and there are multiple reasons why: 1) Editing the project in Anitya (this could create a really strange versions, especially for custom backend) 2) Creating a new project in Anitya (the first check usually retrieves large amount of new versions) 3) Not every project is checked for tarballs (there are plenty of backends, that are checking tags or parsing html, which could be in some cases anything, but versions) 4) Deleting versions in Anitya and retrieving them again (this could create a large amount of new versions that are retrieved) - this is needed if the project was incorrectly setup and needs to be edited 5) Incorrectly setup project in Anitya (this will just send you some weird versions that don't need to be correct at all)
But this is the issue I plan to address in the future, because I understand that the people want to be notified about every new version released upstream not only latest. The issue here is to recognize version that is really new and not something that was already reported, just resend by Anitya. I needd to come with some solution that wouldn't create massive amount of false warnings.
Right now The New Hotness is considered to help primarily with Rawhide and the latest version of the project. I hope it's doing this service well.
Michal
On 09. 12. 21 21:23, Michael Catanzaro wrote:
I honestly don't understand what the problem is. Why not simply notify whenever there is a new upstream tarball, regardless of what the version looks like? Trying to compare versions is pointless because we have as many as four different Fedora releases to maintain at any given time and they could all require updates from different upstream branches.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 09. 12. 21 18:34, Fabio Valentini wrote:
On Thu, Dec 9, 2021 at 2:57 PM Miro Hrončok mhroncok@redhat.com wrote:
...
The only way I can think of to "ignore" pre-releases is to add a "Version filter" on release-monitoring.org ... I've started adding a "alpha;beta;rc;pre" filter (and set the versioning to "semantic" to make sure they are sorted correctly) to all Rust packages I touch, because we don't package pre-releases except in rare circumstances.
Buuuut that only prevents anitya from fetching *new* pre-releases that match that filter, it doesn't remove those that are already in the database, and you won't get notifications for "new" versions that are "older" than the latest pre-release :(
Do you have an example? Because this is a bug. If the project doesn't have some strange versioning scheme the stable should be still considered newer than pre-release and the message should be emitted and processed by The New Hotness.
Michal
Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, Dec 13, 2021 at 11:41 AM Michal Konecny mkonecny@redhat.com wrote:
Do you have an example? Because this is a bug. If the project doesn't have some strange versioning scheme the stable should be still considered newer than pre-release and the message should be emitted and processed by The New Hotness.
Here's an example:
https://release-monitoring.org/project/141635/
After getting notifications for the first 2.0.0-beta releases, I added a version filter to exclude alpha;beta versions. But upstream kept releasing versions 1.9.0, 1.9.1, 1.9.2, etc. after that, which are not considered *newer* than the last 2.0.0-beta version anitya saw, so we don't get bugs for them. So this is not a problem with a strange versioning scheme, but with anitya not removing versions from its database, I guess.
Fabio
Anitya doesn't removing versions on it's own. This needs to be done by admin. The filter is just for the new versions that are retrieved by Anitya. This should be fixed in the future when The New Hotness will learn to work with pre-releases. I also plan to add new option to src.fedoraproject.org to notify only about stable versions.
Michal
P.S.: I removed the beta versions from Anitya project for you.
On 13. 12. 21 18:11, Fabio Valentini wrote:
On Mon, Dec 13, 2021 at 11:41 AM Michal Konecny mkonecny@redhat.com wrote:
Do you have an example? Because this is a bug. If the project doesn't have some strange versioning scheme the stable should be still considered newer than pre-release and the message should be emitted and processed by The New Hotness.
Here's an example:
https://release-monitoring.org/project/141635/
After getting notifications for the first 2.0.0-beta releases, I added a version filter to exclude alpha;beta versions. But upstream kept releasing versions 1.9.0, 1.9.1, 1.9.2, etc. after that, which are not considered *newer* than the last 2.0.0-beta version anitya saw, so we don't get bugs for them. So this is not a problem with a strange versioning scheme, but with anitya not removing versions from its database, I guess.
Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-
Fabio Valentini -
Jerry James -
Michael Catanzaro -
Michal Konecny -
Miro Hrončok