Comment 11 for bug 95419

Here is a real-world example of a need for dependencies (either bug-to-bug, or bug-to-blueprint).

There was a large class of bugs regarding input devices (mice, touchpads, joysticks, etc.) that did not work if you just plugged them in. To get this working required we switch over to the new input-hotplug functionality in X. We set up a blueprint for "X Input Hotplug", to which we referred anyone with questions on it.

Until that functionality was added, we didn't want triagers, bug fixers, etc. to waste time on those bugs. As well, we wanted to set expectations to the users that they wouldn't see the fix until Intrepid. We didn't want to just mark them as dupes though. The workaround we adopted was to prefix the title with [Needs input-hotplug].

It would have been better if we could have more explicitly set up dependencies, such that we could a) hide bugs that couldn't be worked on until input-hotplug was enabled, b) make it easier for the bug reporter to track the status of the pre-requisite bug, c) when input-hotplug was enabled, be able to notify all the bug reporters to re-test.

This style of workflow occurs a LOT with Xorg upstream. The upstream introduces a new technology (xrandr, EXA, GEM, etc.) and so focuses their hardware enablement, bug fixing, and so on around that tech. But until we switch to that new technology we carry a lot of bug reports that are dependent on the switch.

So I understand the relationship complexities mpt identified in comment #7, but that doesn't take away from the fact that there is indeed a need for *something*.