Bug dependencies/relations feature

[daniel]

A simple list of related bugs without logical/implicit constraints might be useful. It'd be nice to be able to relate bugs and issues in a useful manner.

It would also thus allow for reports showing "a bug and all related bugs" in some fashion, which could be neat.

This would also require checking for circular dependencies/relations.

[daniel]

I'm ambivalent regarding this one... Plain comments with TracLinks are quite useful on their own... Maybe we should avoid this feature to avoid complexities.

People who need more strict relationships between issues are probably better off using some dedicated issue tracker, like roundup or bugzilla or something... Just my two.

After all, informal is our game :)

/DanielLundin

[bill@…]

I think a simple ticket_relations table with a schema like this would be simple and useful:

• ticket1 (int)
• relation (text)
• ticket2 (int)

where relation could be (ideas):

• 'blocks': implement bugzilla-style dependencies
• 'is duplicate of': track duplicates
• 'is related to': track related tickets
• 'is subtask of': we often break down large tasks into smaller ones, this would be useful to associate the subtask with the main task

Then, on the ticket page, you could have a separate section that lists ticket relations, in both directions! (e.g. where ticketid == ticket1 or ticketid == ticket2)

[scapo]

essai de gestion de projet

[anonymous]

Here's a use case I consider reasonably important: show only tickets that are "actionable", that is, either do not depend on any ticket, or depend on closed tickets only.

[jonas]

Why was this ticket closed?

[cmlenz]

#226 has been marked as duplicate of this ticket. See that ticket for a proposed patch and further comments, but add anything new here.

Also: resetting assignee to component owner.

[anonymous]

This certainly isn't highest priority.

[david@…]

This is definitely something I would like to see. The "search for all actionable" idea is an excellent one, and the concept of subtasks is also very useful; Mozilla's use of "metabugs" for tracking large projects is something that seems like quite an effective organizational tool.

[chris@…]

I would also like this. I would like 3 items based off this though:

1) child tickets. I can create a parent ticket, then create a child ticket which would allow me to link it. Say I need something done, but I need something else done in another ticket first, I can make a child.

2) Linking similar issues. I would like to be able to say x and y are similar, and when I close x, I'd like to close y with the same resolution code.

3) Hot issues. Pretty much like 2, but basically saying that there is a real issue. I can then notify all the ticket owners who related their ticket to the hot issue, but their ticket will not close.

These would make tickets with trac a lot easier to work with. Thanks a bunch for the great software so far. :D

[havarden@…]

Another implementation for ticket relations. Quick and dirty, but can be extended to support backlinks. Added to show the design ideas rather than the implementation.

[cboos]

The original intent of this ticket was:

• A simple list of related bugs without logical/implicit constraints ...
• It would also thus allow for reports showing "a bug and all related bugs" in some fashion, which could be neat.
• This would also require checking for circular dependencies/relations.

This is fully implemented in TracCrossReferences, so I'll be able to close the ticket when this is merged in the trunk (some cleanups are still needed before that happens).

However, there are other points raised in the comments for this ticket:

• duplicate tickets: I plan to do it like this: when one selects the duplicate resolution, an input field for filling the duplicate-of relation will be enabled.
• child tickets: see #886 for this topic
• linking similar issues: Trac handle this by closing the duplicate ticket with the duplicate resolution (see above)
• hot tickets? (point 3. in the comment above): sorry, I don't get it.

[chris@…]

On linking, sometimes they are similar but not the same. I have a few tickets where one thing is similar to another, and if one ticket was resolved it would really help the other ticket, but overall they are different issues. If I could relate the two it would just be a more beneficial situation.

On hot tickets, this is before I saw the ticket priorities. I guess I overlooked them or something, I withdraw this request.

[cboos]

On linking as you expressed it: well, that would be just a normal cross-reference from one ticket to the other. You can infer the semantic by looking at the context (cross-references are listed along with a fragment of the context in which they were made).

I'll soon start the merging process, a.k.a have a chat with cmlenz :)

[Christian Parpart <trapni@…>]

what's the current state of development of this features? Is it already merged to trunk?

I'd really like to migrate from bugzilla/mediawiki completely to trac, but I can't unless it doesn't support ticket dependencies :)

besides, would it be possible to automatically get generated a tree-view describing current dependencies? (would be a neat feature though)

[cboos]

I first want to have 2 other, less complex, branches merged in the /trunk:

• the category-branch (a.k.a ticket types, #919)
• the intertrac-branch (see InterTrac)

After that, it's the turn of the xref-branch (see TracCrossReferences), for which I plan to add, besides what's currently done:

• adding a time information in the xref table, so that the xrefs can be listed from the most recently created xref to the oldest.
• adding a depends_on field/facet to the ticket table, so that the textual context in which the reference to the dependent ticket was entered can be remembered

About tree-view describing current dependencies?: I could add that, see Xref.get_dag.

[cmlenz]

#1540 has been marked as duplicate of this ticket.

[cmlenz]

Postponed.

[chris@…]

This ticket is a good example of what we need with ticket dependencies:

http://trac.growl.info/trac/ticket/114

[cboos]

Proposed UI

+----------------------------------------+
|                        |               |
|depends on: #123 #213   |  blocks: #456 |
|                                        |
|     ...  ticket description      ...   |
|                                        |
+----------------------------------------+

Attachment:

Change History:
 ....

Change Properties

 ...
 Cc:
 Depends on: _#123 #213________________

Action
  ...

Implementation detail

Until I find a good data model for generalized facets and properties, I've thought there can be an acceptable interim measure: storing the dependency information in the xref.context field. This means that whenever we have xref.facet == xref.relation, the xref.context is actually the full information, instead of an excerpt of some other source.

[Russell Hind <rhind@…>]

hwinkel you removed everyone elses 'cc', not just added yours! Was this intended? If not, please can you cut and paste the cc's above and add them back in again?

[Russell Hind <rhind@…>]

Sorry, looks like I added them back in, didn't mean to do that.

Russell

[bfults@…]

+1 for this feature.

[trac@…]

Akismet

[wkornewald]

What about this:

Instead of adding fields for dependencies you just link to the related tickets as you do now. The ticket details shows non-editable "Refers to:" and "Referred from:" fields with the ticket numbers that were mentioned in this ticket and tickets that mentioned this ticket. A link "Track relations" could give you a detailed overview page that shows the *comments* which related to/from the tickets, so you can immediately get a quick overview of the relevant information including its context in the affected tickets.

That way, you don't track dependencies using an extra field, but directly with the comments which has the following advantages:

• simpler (no need to take care of extra fields)
• more intuitive (you just type the description)
• you can't forget to fill in a dependency field
• it works instantly with existing Trac installations
• you automatically connect the relation with a comment

[cboos]

Replying to wkornewald:

What about this: <snip>

Well, that's great, you just reinvented TracCrossReferences ;) It did just that, including showing a relevant fragment of the comments around the reference, to quickly grasp the context.

I should have produced snapshots at that time, but generalized cross-references were working great ;)

That way, you don't track dependencies using an extra field,

... but it also had provision for explicit linking (the relations part), though that part was never implemented in the UI.

[wkornewald]

Ouch, you're right. I misunderstood TracCrossReferences. I thought it would require a special new link format, but the spec also speaks about general relations. Well, then I perfectly agree your solution! :)

Sorry for the noise...

[mgood]

#4477 has been marked as a duplicate.

[Noah Kantrowitz <coderanger@…>]

Can some people please try out this plugin. Just install it and add a custom text field named "blocking". If you have any ideas for it, please let me know.

[anonymous]

Is it possible to explain the plan here? A lot of people are watching this ticket now, which should say something about the interest in it. I would personally love to use Trac but must stick with Bugzilla until this very fundamental feature is added.

[ThurnerRupert]

so currently there is:

• duplicate plugin: http://tn123.ath.cx/TracDuplicates/
• master-ticket plugin: TracHacks:MasterTicketsPlugin

marked #5197 as dupl...

[anonymous]

cc changed: added henry78

[anonymous]

Replying to Noah Kantrowitz <coderanger@yahoo.com>:

Can some people please try out this plugin. Just install it and add a custom text field named "blocking". If you have any ideas for it, please let me know.

Noah's plugin is working great for me so far and was a trivial install. Copy to Libs, add custom ticket type, and off you go.

(As an aside, throw my hat into the "Why isn't this a default feature?!" pile.)

[anonymous]

Is there a time schedule for this task completion? Lack of this feature in the core cripples Trac and prevents it's better adoption...

[anonymous]

Mylyn allows grouping by sub-tasks. Lack of this feature is degrading user experience from PM-perspective...

[alon.barlev@…]

Hello,

I've read all related bugs, and could not figure out how this feature can be available using TracCrossReferences.

I don't care how it is called, master, dependency, blocker, relates.

What I require: bug A and bug B should be handled when bug C is completed. The tree bugs are assigned to different people. When bug C is closed, bug A and bug B CC list should be notified, so they know to perform whatever needed.

If I write #31 in bug text, say "This bug is depended on bug #31", and this bug is closed, then I the text is modified, example "This bug is depended on bug #30", this change in the status/text may trigger notification as if someone changed the bug text.

As far as I understand, changing the status of TracCrossReferences, does not cause all the references to be modified and treated as changed, so that subscribers get notification.

So any solution within current Trac features? I am afraid to install external plugins as it would break future migration.

I don't know how people may be expected to manage bug repository without relationship, how do you do this?

Thank you

[nruffel@…]

This is definitely a must have feature!

[nkantrowitz]

Any objections to closing this now that MasterTickets is stable and usable? It could be further generalized to support mutliple types of relations, but I think that should be left as a feature request on the plugin.

[anonymous]

Using third-party plugin for such essential functionality looks risky. What about migration path and compatibility issues? There is no guarantee on the future compatibility of MasterTickets? and Trac. Besides, MasterTickets? looks quite limited. Trac is great, I bet you can do better than that.

I can't believe that Trac team avoided implementation of such essential feature for so long (this ticket is 4+ years old). I love Trac but it's unusable in large projects because of things like this. Sad.

[cboos]

Replying to anonymous:

Using third-party plugin for such essential functionality looks risky...

See googlegroups:trac-dev:31612a1978ef2609 for a follow-up on this.

[alon.barlev@…]

I cannot believe this! So trac is not going to be decent bug tracking system... OK, I will wait for some better solution. This is sad, as the trac project is so close to provide proper functionality.

[anonymous]

Me neither. Why is this bug closed? If the use of an external plugin isn't satisfying, then this bug should be just a feature request, but not closed. (see type: enhancement)

[armando@…]

cboos -- that google link is interesting, but doesn't really defend closing this bug (if anything it just reiterates that the feature is sorely missed).

I think that for most of us, this has sealed the deal for continuance of use of Trac. There's no point anymore, it seems. For 4 years, people have been saying "Hey, we need this feature," and the core team has decided to ignore the desires of it's users, in the end. Honestly, I find it quite depressing. I mostly like Trac, but now that this issue has been tabled indefinitely, I'm officially giving up.

It's sad that a mish-mash of Wiki and Bugzilla can be more useful than the otherwise quite elegant Trac.

Also, I don't understand the purist idealogy that makes one /not/ want this feature in Trac, and I suppose I never will.

My 2¢, armando

[just use redmine]

just use redmine www.redmine.org it is not as full-featured as trac but it is so much easier to set up and maintain. It's also catching up quickly. I believe it is less than 6 months old.

[anonymous]

I agree with others here that the lack of this feature is what made me not use Trac. I was so unhappy with the available choices out there (integrated bug tracking, task tracking, wiki, timelines, etc.) that a group of developers and me created a new SF.net project from scratch to do all this. We've been working on it for about 6 months, and one of the key design goals is that it be visually appealing and have a great interface. Trac was so close but some key features like this one made it unusable for us.

I'll post again when we have our first release, though we've been using our new one internally for the last 2 months for testing. :)

[armando@…]

On cursory examination redmine seems pretty great. I hate that RoR apps tend to take a lot of memory, but if it delivers what it claims (I especially like the multiple SCM integration), I'll be pleased.

Thanks for all the fish, Trac.

[anonymous]

We (software development department of a major .eu telco) have migrated from Trac to Redmine recently after a long decision. Trac is a very, very good piece of software, but when it comes to a multiproject tracking, dependencies, time tracking - Trac looses the game.

We are using redmine for about two weeks for now and we love it.

Still, we'll keep on pulse of Trac because we love it, too and wish the best to the project:)