fedora-qa

#356 Blocker Proposal is Slow
Closed: Fixed Opened by tflink.

Closed: Fixed
Reopen Issue

= problem =

While the blocker proposal functionality does work, the process of actually proposing the blocker is very slow - it appears as if the page has just stalled for a while as the request is being submitted to bugzilla

Outside of being an annoyance, there is a possibility of users refreshing the page during submission, which would trigger a second proposal. This isn't the biggest issue ever but could end up generating extra comments in bugs.

= analysis =

It would be better to show users a "bug is proposing" page until the proposal is complete - that way they wouldn't be tempted to refresh the page and if the page is done correctly, it wouldn't matter if the page was refreshed or not.

= enhancement recommendation =

I have some ideas on how to go about fixing this but I need to explore the details before figuring out if any of them are even practical or how long the implementation would actually take.

I did some digging into this and I don't think it's practical to plan on this for Fedora 19. It would be great but the blocker tracking app wouldn't be the only Fedora-related app that has some slow postings and I think our resources could be better spent elsewhere for now.

Moved to [https://phab.qadevel.cloud.fedoraproject.org/T33 https://phab.qadevel.cloud.fedoraproject.org/T33]. If interested, please add yourself to CC there. Closing.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/quality/tickets/issues/356

Please continue any further discussion there.
Metadata

enhancement

None
None
Low
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.