You mean patching Pagure to allow for voting? It's pretty specific to our use case, I'm not sure if Pagure would be interested in having that. There is something similar on Github/Gitlab by acking/nacking a pull request, but that is for PRs where it makes sense. We would need to use it on tickets, where it generally doesn't make much sense. I also considered voting by adding thumbs-up/thumbs-down reactions (already supported by Pagure), but that is a process that doesn't create any activity log and the result can be arbitrarily changed at any time, even after voting has ended.

The process of VOTE +1/0/-1 and updating the summary is very lightweight on the blocker bot functionality (it should be really trivial to implement) and it doesn't hurt us much if the bot goes unresponsive - counting manually is not that much work. I see voting in BBA as a much more daunting task, because of authentication, notifications, long term logging, making sure the service is up at all times, etc. Also it wouldn't make much sense to have discussion and voting at two separate places, which means having the discussions in BBA as well, which brings yet more requirements.

The other part of the bot, mainly updating blocker bugs in Bugzilla automatically, was something we've talked about a long time and that can't be done with any Pagure extensions etc.

 

That is a valid concern. But, we already have three systems, the third being IRC :-) And that would get replaced by Pagure. If IRC is down, our processes are negatively affected (the same would happen if Pagure was down). My main goal is to avoid being overly reliant on BBA. If Bugzilla or Pagure are down, it's a Fedora-wide crisis and it will get resolved promptly. If BBA is down, just a few people from our team can do something about it, and if that is a complex issue, the priority to getting external help is much lower than with Bugzilla or Pagure. I also want us to stay away from the sysadmin roles as much as we can. So BBA (including the blocker bot, if we want to distinguish that) plays, in my ideal world, just a support role, but we don't depend on it. If things break, we can always do the same thing manually (list proposed blockers in bugzilla, have the discussion there or elsewhere, then set the right fields, etc). And that principle is valid even in the proposed scenario.

You are right that synchronization issues might occur, especially when we start displaying the same data in several places. The canonical source is and will be Bugzilla, but we display blocker/FE status in BBA and now the same info would be visible through Pagure ticket tags. That... might not be a good idea. I was thrilled by the idea of having an easy-to-look-at and easy-to-use list of current and past blockers/FEs (because often I need to find a past accepted/rejected blocker and that is a painful experience using Bugzilla), but it's not necessary. All the tags are just sugar on top. Perhaps we should start without it, and add it later, if we feel it would be useful and we have no synchronization issues.