Comment 7 for bug 95419

I've long thought adding dependencies would be a good idea, but over the past month I've changed my mind.

The problem is that when a bug tracker has dependencies, they're used to mean a variety of different things:
* Work on X can't begin until Y is finished.
* Work on X can begin, but can't finish until Y is finished.
* X could be finished without Y being finished, but the software wouldn't make sense to users in that state.
* X might still be an issue, but it's difficult to tell because of Y.
* Fixing Y would be one way of fixing X, but not the only way.
* X is divided into two tasks, Y and Z.
When people assume all dependencies are of the first sort, development is slowed unnecessarily. (And in software development, the first sort happens less than it does in other types of project, because programmers can use method stubs to simulate the code they're waiting for.)

I often deal with other important relationships between bugs too:
* If X was fixed, Y would become invalid.
* Y is similar to X, and testers should be careful not to confuse them.
* Y is a regression of X.
* Y is the unfixed remainder of X.
With all these relationship types -- including pure "Work on X can't begin until Y is finished" dependencies -- I think the clutter of an extra field outweighs any benefit of having a machine-readable relationship. Ubuntu and Launchpad itself, to name two, seem to have survived for years without missing bug dependencies.

Instead, people can update a bug's description to link to other relevant bugs. Perhaps we could add a hint about doing that to the caption for a bug's description field.