I found an issue. The stg wiki page doesn't correctly include links to the stage bugzilla, instead they link to the production bugzilla (the numbers are for staging, just the links are invalid, so all you need need to do is to add "stage" in the middle and you get the right link). The problem is that when creating the wiki, it uses the rhbug keyword:

| Fedora 37 Beta || BetaBlocker || F37BetaBlocker || [[rhbug:1996156|1996156]]

It is not the usual template, instead it's some kind of a builtin plugin or something? I don't know how to see the source code/documentation for rhbug, whether it supports links to bugzilla.stage.redhat.com, or whether there's a similar keyword for it, etc. We can either ignore it (the staging wiki is just for us anyway), or I can make the script include a full URL (at least for staging) instead of the rhbug keyword).

why did you want to update staging anyhow? isn't staging bugzilla regularly re-synced from prod bugzilla, so it'll get the trackers that way?

also note that I found bzapi.logged_in() actually crashes if you're not logged in.

Other than those issues, this looks fine...

Why? I don't mind a change to /usr/bin/python3 but there's no real clear benefit to using env AFAIK. We do not use it in standard shebangs for Fedora packages.

why did you want to update staging anyhow? isn't staging bugzilla regularly re-synced from prod bugzilla, so it'll get the trackers that way?

Unfortunately it isn't. If "regularly" doesn't mean every few years. If I want to test BBA against stg, I need to create the trackers manually, which I did up until now and hated it. Now I realized I could use your script.

also note that I found bzapi.logged_in() actually crashes if you're not logged in.

Interesting. It works just fine for me:

$ python
Python 3.10.4 (main, Mar 25 2022, 00:00:00) [GCC 12.0.1 20220308 (Red Hat 12.0.1-0)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import bugzilla
>>> bz = bugzilla.Bugzilla(url='bugzilla.stage.redhat.com', use_creds=False)
>>> bz.api_key
>>> bz.logged_in
False
>>> 
$ pip freeze | grep bugzilla
python-bugzilla==3.2.0

I don't mind a change to /usr/bin/python3 but there's no real clear benefit to using env AFAIK. We do not use it in standard shebangs for Fedora packages.

Yes, because in standard Fedora packages you don't want to pick up a different python interpreter from the environment. Miro et al. are trying hard to avoid any external influence (a most recent example). But for scripts that you run from a development directory, being able to run them from a virtualenv makes the experience much better (./updatetrackers instead of python updatetrackers). For actual installation (if it happens, not in this case), the shebang can be replaced with a hardcoded path, or a script created through setup.py, or a Fedora macro can take care of that, etc. I think we do it somewhere.

But I don't have any strong feelings here, it's just that I'm used to use env python3 for development-related scripts and simple tools without installation, and so I changed it. I can easily continue to run this is as python updatetrackers, I don't mind.

Merge whenever you feel ready with whichever changes you want ;-)

I was kinda expecting a resolution to the rhbug thing. So I looked into it now. It's an interwiki link: https://meta.wikimedia.org/wiki/Help:Interwiki_linking . The list of them is at https://fedoraproject.org/wiki/Special:Interwiki . However, it's not edited via the wiki, it needs to be edited directly in a database table, apparently. We'd have to file an infra ticket. I guess the sensible thing to do would be to ask for a rhstgbug entry or something which we could use to link to staging.

Ah, rhbug, I completely forgot about it :) Thanks for the investigation. I feel bad bugging infra about such a trifle. No-one cared about the stg page until now (why should we). It's staging and for our private use anyway. If that still bothers you, I'll implement using direct links instead of rhbug.

I updated the PR with a fix for the staging issue, plus some other tweaks. I felt like the use of global vars was kinda superfluous, we can just pass the values from run() to the necessary functions. And I'm trying to standardize on double quotes (I know it's not consistent in the rest of the file yet!) Will merge like this. Untested, let's hope it works. I guess I'll try and remember to run it on stg before prod next time. :D

I felt like the use of global vars was kinda superfluous, we can just pass the values from run() to the necessary functions.

It's hard to strike the balance between abstraction, readability, maintainability, encapsulation, testability and all those other complex words :-) I personally don't see a problem in using global variables as long as they are mostly read-only (except some startup initialization). They make the code simpler.

And I'm trying to standardize on double quotes

Good luck :-D When I have time, I intend to try to use some code formatter (e.g. black) in my projects and see if I can a) live with the result b) be happy to let go and completely stop thinking about formatting when writing code.

It's a bit subjective yeah, in this case I kinda preferred how this way all the discovery and passing of the variables happens in one place rather than them being declared at the top and then having to use global later on...

I use black on most of the projects I maintain now, but this repo is shared and isn't a straightforward single python project so it's a bit different. It'd be nice to write tests for each script and a unified tox config to run them all plus linting/formatting, though...