You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
..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 text was updated successfully, but these errors were encountered:
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?
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.
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.
These days, all tracking of Fedora issues no longer happens in bugzilla.redhat.com:
..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 text was updated successfully, but these errors were encountered: