Sub-Blockers are not detected as proposed or accepted blockers

mkrizek commented

2014-01-13 14:00:18 +00:00

Moved from trac https://fedorahosted.org/fedora-qa/ticket/313 :
"When bugs are marked as blocking existing proposed or accepted blocker bugs, they are not detected by the sync algorithm and thus are not detected as blocker/nth bugs

Current Example: 852845 is blocking 850775 which is an accepted blocker but doesn't show up on the blocker tracking page"

Moved from trac [[ https://fedorahosted.org/fedora-qa/ticket/313 | https://fedorahosted.org/fedora-qa/ticket/313 ]]: "When bugs are marked as blocking existing proposed or accepted blocker bugs, they are not detected by the sync algorithm and thus are not detected as blocker/nth bugs Current Example: [[ https://bugzilla.redhat.com/show_bug.cgi?id=852845 | 852845 ]] is blocking [[ https://bugzilla.redhat.com/show_bug.cgi?id=850775 | 850775 ]] which is an accepted blocker but doesn't show up on the blocker tracking page"

tflink commented

2014-01-14 18:47:50 +00:00

Contributor

This has been open for 1.5 years or so (from trac) and nothing catastrophic has happened. To me, this fits nicely as a "wishlist" feature/fix

adamwill commented

2020-03-24 18:35:33 +00:00

Owner

I'm actually gonna raise the priority on this because it's quite bad, now we trust blockerbugs quite a lot - we run blocker review meetings off it and we also use it for generating the stable push and candidate compose requests. This can potentially lead to us flat out leaving out bugs and updates we should be tracking and pushing. The only failsafe here is for the people running meetings and filing requests to check the listed bugs one by one for dependencies (or just remember that some of them have dependencies, every time they do anything). As that person is usually me, I try to do this, but I can tell you from past experience I'm not perfect :D

It may be quite difficult to implement this well, though. Ideally we'd want a nice accurate representation of these relationships - the database should be able to express them well and this should be shown in a good way in the UI and also in the IRC and request templates. That's probably not trivial to do. It might be easier to at least implement something simpler, like a big red 'THIS BUG HAS SOME DEPENDENCIES!' flag in the web UI view at least.

I'm actually gonna raise the priority on this because it's quite bad, now we trust blockerbugs quite a lot - we run blocker review meetings off it and we also use it for generating the stable push and candidate compose requests. This can potentially lead to us flat out leaving out bugs and updates we should be tracking and pushing. The only failsafe here is for the people running meetings and filing requests to check the listed bugs one by one for dependencies (or just *remember* that some of them have dependencies, every time they do anything). As that person is usually me, I try to do this, but I can tell you from past experience I'm not perfect :D It may be quite difficult to implement this well, though. Ideally we'd want a nice accurate representation of these relationships - the database should be able to express them well and this should be shown in a good way in the UI and also in the IRC and request templates. That's probably not trivial to do. It might be easier to at least implement something simpler, like a big red 'THIS BUG HAS SOME DEPENDENCIES!' flag in the web UI view at least.

adamwill commented

2020-03-24 18:35:33 +00:00

Owner

Metadata Update from @adamwill:

Issue priority set to: High (was: Low)
Issue tagged with: bug

**Metadata Update from @adamwill**: - Issue priority set to: High (was: Low) - Issue tagged with: bug

kparal commented

2021-06-24 15:25:57 +00:00

Owner

Commit e5abd4ec relates to this ticket

Commit [e5abd4ec](https://pagure.io/fedora-qa/blockerbugs/c/e5abd4ec) relates to this ticket

kparal commented

2021-06-24 15:31:25 +00:00

Owner

The commit above makes the UI aware of bug dependencies (an icon shown, etc), but doesn't track them. In a second step, I'd like to show the first level of dependencies directly in the UI (and any more nested deps would be shown simplified, as above).