Has anyone poked at scoping out the work required for either the bot or
the enhancements we would need for pagure?
Lukáš Brabec looked into it, and creating a new Pagure ticket is a matter of a few lines of code (already written). Extending BBA with a "discussion link" in each blocker row should be trivial as well. I think that's all we need for trying it out.
The blocker bot watching and updating the issue should be fairly easy as well, I hope, but as described above, we've hit an issue where Pagure API doesn't allow comment editing. Lukáš implemented a workaround that adds a new metadata field on the right side of each Pagure ticket showing the count summary. It's barebones, but at least something. We've haven't yet looked into writing the listener code, that would listen for Pagure events on the message bus and react to them. We also haven't looked at Bugzilla updater as described in the proposed workflow (that's really a cherry on top, we don't need it right away).
It might be interesting to look at porting the blockerbugs app to
django if we can make use of some existing django plugins. In the past,
I would have hesitated to do this because of the packaging requirements
and the amount of fun that plugin ecosystems can present but we're
going to have to move to openshift sooner than later which makes the
prospect of using something like Django a lot less daunting.
Ehh. Hmm. I'd really like to avoid being responsible for showing the discussion, handling authentication, sending out notifications, etc. Right now, if BBA is down, we're fine, it's just less comfortable. If we own the full process, it's much more demanding. Also, converting BBA to Django and using some discussion+votes plugins sounds like more work than those quite simple changes in BBA + blocker bot. Plus Josef is the only one except you who has some Django experience, I think.