On 08. 04. 19 1:32, Robert-André Mauchin wrote:
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.
For some packages it makes sense to be able to opt-out.
Some of them release versions that are not OK for Fedora, some only go released
together with another packages, some release 3 times a day.
There might be other reasons.
I would suggest the following approach:
1. Switch everything that was converted from Pagure. Keep anything disabled by
later commits.
2. Mass e-mail the affected maintainers about this with specific instructions
to opt-out if needed.
For the repo maintainers, I suggest demanding reasons before merging a Pull
Request that sets a package to no-monitoring.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
