= bug description = A bug with Blocks field set to 689509, 980651, 980656 does not show up on the tracker's final blocker page; probably because it was rejected as a beta blocker therefore it has Whiteboard set to RejectedBlocker.
= bug analysis = https://bugzilla.redhat.com/show_bug.cgi?id=864198
= fix recommendation =
Ideally a way for rejected blockers to be differentiated from separately proposed blockers; e.g. Whiteboard RejectedBetaBlocker vs RejectedFinalBlocker.
Otherwise, if approved for final blocker, it seems like it will just suddenly appear in the final blocker listing rather than having been on notice as a proposed final blocker.
Yeah, since we have no way of determining which tracker the "!RejectedBlocker" refers to, the app assumes that it's rejected for all of them.
I removed the "!RejectedBlocker" and blocks on the beta tracking bug so that it'll be detected as a proposed final blocker.
Ok so this was user error. I'm supposed to remove both Whiteboard: RejectedBlocker and the Blocker: blockbug# when reproposing for a different blocking bug. Sorry about that.
Yep, sorry for the finicky process :( Obviously if we weren't abusing BZ for this purpose we could make it more robust.
One question that occurs is whether the blocker bug proposal app handles this properly when re-proposing a previously rejected bug - tflink?
Replying to [comment:3 adamwill]:
Yep, sorry for the finicky process :( Obviously if we weren't abusing BZ for this purpose we could make it more robust. One question that occurs is whether the blocker bug proposal app handles this properly when re-proposing a previously rejected bug - tflink?
We've had this conversation before and I still don't have a strong opinion on it. We can change the app to ignore !RejectedBlocker in the whiteboard but in my mind, that brings up a question of whether we want to just drop that part of the process entirely.
Login to comment on this ticket.