Comment 15 for bug 95419

I'd have to say +1 on the idea of adding bug relationships, simply for the fact that it makes it easier to track certain types of things. Take, for instance:

User A reports a bug, saying that product Foo doesn't work with Baz (a Widget X) written after 2007.

User B reports a similar bug, but not quite identical, saying that product Foo doesn't work with recent Baxen (also a Widget X).

Developer finds out that this is because product Foo does not support a certain new standard that it should support, and opens a bug to call for this feature to be implemented. Additionally, there are slight differences between the base standard and the Baz and Bax products that Foo doesn't work with. However, those two bugs are obviously not the third bug, and they obviously depend on the third bug. So, their status should be “Blocked” and there should be an information field somewhere near the top or the right side of the page which states “Blocked By” or “Blocking” and one or more bugs (of course it would not show up when there are zero bugs).

While it may not be used by everyone, it could very likely be done in a non-intrusive fashion such that bug dependencies of even the most primitive sort are possible and easily used. The system doesn't need to be complex, and yes that means that different people will probably mean slightly different things about what dependencies mean, but (at least in my experience) the reason for one bug blocking the second bug is pretty easily discovered by looking at the source code, the bugs, and just knowing the relationship exists. Figuring out the details of what the precise relationship between the bugs is easily derivable from knowledge, we just need (okay, really really want) a way to put that knowledge there in a consistent, standard fashion to begin with.