Along with #114, another case when Pagure issues should be closed (IMO) is if the proposed bug itself is closed. We don't treat closed bugs as 'proposed' or 'accepted' blockers elsewhere in the process (including the IRC template used for the synchronous blocker review meetings), so the async voting system shouldn't treat them as such either.
Of course, we should also be able to re-open the Pagure issue if the bug is re-opened...
Agreed in principle. But. This might actually be a non-issue. We specifically decided we don't want to try to mirror bug status in pagure tickets. That includes syncing bug title, target release, proposed milestone, blocker/fe/0day/previousrelease request, etc, including open/closed state. It was you who said it's not a good idea to do this at least in the beginning, because it brings a ton of complications (and it does). Initially I thought people would use the Pagure repo to browse through tickets, filter according to milestones, etc. You convinced me to think twice. So now the expected workflow is to look into BBA and click the link next to see the Pagure discussion ticket. And once a bug is closed, it disappears from BBA. And so it doesn't really matter if the underlying ticket is open or closed, the same way it doesn't reflect other properties of the bug report. Does it make sense?
If we want to keep the Pagure repo "clean", we can close the tickets manually for now, and implement at least bug open/close state syncing in the future (if the PoC is well received).
Hey, no-one ever said I had to be consistent ;)
So, I don't recall if that's exactly what I said, but I guess a thing I didn't think of at the time is: notifications! We get notifications when Pagure issues change. So I wound up looking at issues 'directly' in Pagure because I'm getting email notifications for them and clicking on the links in the notifications...maybe we could look at whether it's possible to get Pagure to suppress notifications for our repo, or something?
The current stg Pagure project is here:
You can simply unwatch the project if you don't want to receive the notifications (and anyone else can still watch it). Personally, I'll keep the notifications in the future, because we don't have any BBA notifications, and Pagure notifications remind me that I can immediately go and discuss a blocker/FE proposal. Even if I didn't click on the Pagure link but opened BBA instead, I still find it useful. Of course, this will be much better when we use our production instances and you don't need to remember http://blockerbugs-blockerbugs.apps.os.fedorainfracloud.org/ ...
I wonder how to improve the ticket content/notifications without possibly providing stale data...
In #114 we have implemented mass-closing of all Pagure tickets. In #116 we implemented a picture that shows some bug metadata in its description, and it says "BUG CLOSED" if the bugzilla is already closed (example) - yes, it takes some time to see it, but that's because Pagure and libravatar.org is extremely slow :-(
@adamwill Is this enough to consider this ticket resolved? While it doesn't do exactly what you asked for, I think we covered the reasons why you asked for it.
to comment on this ticket.