No way to express that bug A cannot be fixed until bug B is fixed

Old related thread on launchpad-users: https://lists.ubuntu.com/archives/launchpad-users/2006-March/000110.html

Although that thread seems to suggest that dependencies shouldn't be implemented, it'd be a very useful feature to have.

Is nobody working on this? This seems like a key missing feature.

Yeah, this would be nice to have. At the very least, it would be useful to mark bugs as "waiting for other dependency to land" or something.b

I need this is as well please.

In my case Bug 91013 is blocked on bug 54359, bug 127138, bug 76083, bug 66839, and bug 81575

Another thought:

Once this is implemented you can be sure that there will be other bugs filed that say

1) "Bugs which are no longer blocked should automatically send an email to subscribers notifying them of such". You might want figure that into the design of the solution to this bug.

2) "Please use an icon and/or colour to display that a bug is blocked on +bugs"

3) "Please use an icon and/or colour to display that a bug is a blocker on +bugs"

4) "Please allow for searching on bugs which are blockers"

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.

What about just a "related bugs" field that creates forward and backward links?

Instead of a field, why not infer related bugs (back and forwards) from the description and comments?

because software like launchpad is meant to make life easier. relevant information should be easily accesible and in the same place every time.

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*.

Also, if I agree that dependancies can be complex for very big project like Ubuntu, it's more than useful for small projects. (And Launchpad is hosting a lot of them currently).

When 2 or 3 people only are working on a small project, it makes a lot of sense to say that "new feature 1" and "new feature 2" depend on "refactor the main class". Also, I cannot even imagine a free software developper that would say : "Because this bug depend on something else, I will not work on it at all".

So please, add a "depend of/is blocking" field with a free interpretation of its meaning. People that don't like it would not use it anyway.

Perhaps bugs could have a "what links here?" link that lists all other bugs and possibly other occurences that mention this bug. This would add a bit more power to relationships expressed in descriptions and comments.

Daniel, thank you for your comment. What you are suggesting is something else entirely. Please open a new ticket.

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.

Hmm, I think I got to the party late, but:

Having worked in a tracker that had "X blocks Y"-style dependencies, I really liked it. We used it a lot, and it helped us remember what was blocking what. The complexities raised by Matthew Paul Thomas in comment #7 are real, but just because formal dependency relationships can't easily express all of those subtleties doesn't mean such relationships are useless. They are still a win, even if they don't solve everything.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Perhaps we can have more categories of relationships to properly
reflect the relationships themselves.

Karl Fogel wrote:
> Hmm, I think I got to the party late, but:
>
> Having worked in a tracker that had "X blocks Y"-style dependencies, I
> really liked it. We used it a lot, and it helped us remember what was
> blocking what. The complexities raised by Matthew Paul Thomas in
> comment #7 are real, but just because formal dependency relationships
> can't easily express all of those subtleties doesn't mean such
> relationships are useless. They are still a win, even if they don't
> solve everything.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkqoDagACgkQTniv4aqX/Vl+ZQCfZsMnIVUsfyrpztKyh9bm0v36
SPsAmwT85qsrA6seMMeB/qwGC/OT9bqf
=RdrD
-----END PGP SIGNATURE-----

Its easy to lose track of bugs that depend on updates to 3rd party dependencies. It would be great to have a 'Update Launchpad to use Python 2.6' bug blocking all the bugs we are deferring until that is done. This also ties into bug heat - the blocked bugs would become hot once they are unblocked. I just faked this today with a specification, but it does mean we are going to have a high priority bug sitting on our reports and annoying us for several months until we actually are able to work on it.

Bugs not getting attention because they're low-priority that block high-priority bugs is the use I'm imagining for this.

The https://lists.ubuntu.com/archives/launchpad-users/2006-March/000110.html URL is broken and http://web.archive.org doesn't have a copy.

Hey,

haven't followed LP development for some time. Any update on this? Still an issue?

Cheers,
  Stefan.