Re: Anitya Upstream Release Monitoring - Dial back Auto-Bugzilla ticket generation

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

 



> I assume most package maintainers are not simultaneously upstream for their packages.

I would definitely agree with that! Just to clarify further, I guess i was hoping that Anitya could be smart enough to detect that a bugzilla wouldn't be necessary to be created in the event it's found already upstream i Fedora given this threshold I'm asking for.

In my situation, is it valid to just turn this off completely and not have a Bugzilla ticket created at all?  My passion for Fedora is enough that it's literally the next thing on my list to do once i push to PyPi :)

Chris

On Sat, Feb 1, 2020 at 4:11 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
On Sat, Feb 1, 2020 at 10:06 PM Chris <lead2gold@xxxxxxxxx> wrote:
>
> Hi,
>
> I was just curious if there as a way to dial back the Upstream Release Monitoring and the automatic Bugzilla ticket generation from it?
>
> I pushed a new release of my software to PyPi and I swear before I even got access to the shell again (from the successful twine upload message), I was already alerted by Anitya that a Bugzilla ticket has been created.
>
> Can we dial this back and give ... say.. 24 hours or so before creating these tickets (when a new version is detected)? Just a question is all.  It's also possible this is just it's an option that I carelessly overlooked (i do tend to do these things)?
>
> I think the ticket is fantastic and very useful, I just think it should be triggered after a longer wait period then 3μs :)
>
> Thoughts?

For my part, I like the anitya bugs to be filed as soon as it detects
a new version, without any artificial delay.
Your situation is a bit different, since you actually released the new
version yourself.
I assume most package maintainers are not simultaneously upstream for
their packages.

Fabio

> Chris
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@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