RFE: ability to designate updates as addressing issues in any tracker, not just Bugzilla
AdamWill opened this issue · 4 comments
These days, all tracking of Fedora issues no longer happens in bugzilla.redhat.com:
- The desktop team directs issues for GNOME to gitlab.gnome.org in almost all cases
- The IoT team has a tracker at https://github.com/fedora-iot/iot-distro
- The Fedora CoreOS team has a tracker at https://github.com/coreos/fedora-coreos-tracker/issues
- The Atomic Desktop folks have a tracker at https://gitlab.com/fedora/ostree/sig/-/issues
..that's just a few, I'm pretty sure there are several others. It's conceivable that a Fedora update could address an issue in any of those trackers, or others.
I think it would be good if you could designate an update in Bodhi as "addressing" an issue...pretty much anywhere. We should accept arbitrary string entries (edit: or maybe just valid URLs?). That, at least, would let other systems that do similar work - like https://pagure.io/fedora-qa/blockerbugs - handle this situation: if we want to allow there to be "blocker bugs" in places other than Bugzilla, it works best if blockerbugs can still know and track the state of an update that "addresses the blocker".
Bodhi can additionally and optionally have more advanced handling of trackers that it recognizes. e.g. bugzilla.redhat.com can be a special-case tracker where Bodhi can post comments and change the status of the issue. Maybe there would be other special-case trackers which Bodhi would have powers to do stuff in, or at least just provide a "nicer" representation of the "addressed issue" than the literal URL string of it.
I haven't looked into how much work this would be, just wanted to write the idea down.
The openSUSE Build Service lets you use a specific naming/shortcut convention to reference different trackers. It might be a good idea to reuse that concept here?
https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Current_set_of_abbreviations
yeah, I'm aware of that, I think it actually originates in openQA (I contributed some of the definitions there :>). the implementation can get a bit finicky, though. I'm kinda not sure whether it's worth the work. Would have to figure it out while actually trying to implement that.
The IoT team has a tracker at https://pagure.io/fedora-iot/issues
IoT migrated to GitHub - https://github.com/fedora-iot/iot-distro
(Will make a PR to update the landing page of that pagure space to note the new location)
Bodhi has some sort of modular approach to interface to bug trackers, most of the code is in bugs.py
in the Bugzilla
class, so I think it can be extended with other interface classes. However, in time we always take for granted that Bugzilla was everything we needed, so there's other code scattered through other modules that relies on that assumption.
It would be really nice to rewrite everything to be really modular and compatible with different trackers, in fact it will soon be required to do so if Fedora plans to switch from Bugzilla to something else. But it will be a really though task involving deep changes in database schema also.