Re: Registering Python packages with Anitya and the "no-monitoring" option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/7/19 9:27 PM, Charalampos Stratakis wrote:


----- Original Message -----
From: "Robert-André Mauchin" <zebob.m@xxxxxxxxx>
To: "Miro Hrončok" <mhroncok@xxxxxxxxxx>
Cc: devel@xxxxxxxxxxxxxxxxxxxxxxx
Sent: Monday, April 8, 2019 1:32:58 AM
Subject: Registering Python packages with Anitya and the "no-monitoring" option

Hello,

I have worked on my script to register packages with Anitya this week-end:
https://gist.github.com/eclipseo/fbc52aeebccb7f560221bd40ec28b6af

It now handles all backend that Anitya supports.

I have ran it on Python 2661 packages and this resulted in 637 new packages
being registered. Michal Konecny still needs to do something for the new
hotness to pick them up.

However I already noticed that a large number of packages have set "no-
monitoring" in Pagure. A lot of that are old packages ported from pkgdb and
it
seems it defaulted to "no-monitoring" back then. As a results many bugs won't
be filled even if the packages is outdated.

I wish we forbid the use of "no-monitoring" and force maintainers to track
updates through Bugzilla, so updates are always linked to a bug number. So we
would convert all existing packages from "no-monitoring" to "monitoring".
Any input regarding this proposal? Would many of you be against such a
change?
Right now we have tons of packages left unmaintained as a result.

I'm all for enabling monitoring everywhere, as I have myself lost way too many
updates of my packages due to it being disabled after the migration from pkgdb.

However I'd also like some simple way to opt out as well. Some packages have
really aggressive release schedules (looking at you boto3) generating too much
noise, and having to file PR's here [0], skimming through all the fedora rpm's
to find my package in order to tweak release monitoring is really not the most
intuitive approach.

[0] https://pagure.io/releng/fedora-scm-requests/blob/master/f/rpms


Indeed, a more reasonable approach was discussed recently[0]. I think it
would be best if that (or something better) be implemented before
flipping on monitoring in any large-scale way.


[0] https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/RNUBMEG6GOY3V2LNXV7PX4P56CE4NSEN/#24A7EJZI4P6Q47XEUA52RWTOQVB2MU3Y
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux