Flyspray - The bug killer!

  • Status Closed
  • Percent Complete
  • Task Type Feature Request
  • Category User Interface
  • Assigned To
    Mac Newbold
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version 0.9.8-devel
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Flyspray - The bug killer!
Opened by Mac Newbold - 10.06.2005
Last edited by Mac Newbold - 09.08.2005

FS#573 - task dependency graphs or visualization

Currently, you can look at a task and see which tasks it depends on, and which tasks depend on it. But there is currently no way to see any further than the set of tasks that are directly related to the task you are viewing. I think it would be really useful to have a way to view more than just those simple dependencies, and be able to get a big picture of what your dependency graph looks like. When doing it by hand, I had 14 tasks tied together with dependencies, and it took over 10-15 minutes to get the graph, when programmatically, it could be instant.

Generating a list of edges from the database is really easy. The only hard part is doing a good layout of the nodes (tasks) and edges (dependencies). Lucky for us, there are a bunch of good layout packages available, like dot and vcg, but they would require extra software to be installed on the server with flyspray.

For rendering, dot and vcg will do it for you, giving back an image, or you can get them to return a text description that is annotated with (x,y) positions for the nodes. That could then be used by flyspray itself to render the image using the GD image library in PHP for example, or it could be rendered in HTML in some nice way, using the positions to place divs or other objects on the screen.

Current status: I've got an implementation that uses dot to generate an image. The plan is to incorporate it as a div that starts out hidden in the details page, and can be expanded with a click. The code is very fast (less than 1/4 of a second), and doesn't seem to generate excessive load on the server. It appears to work very well, even for complex graphs.

The task blocks this from closing
ID Project Summary Priority Severity Assigned To Progress
612 Flyspray - The bug killer!  FS#612 - add WebDot capability to task visualization  Low Medium Mac Newbold
Closed by  Anonymous Submitter
10.08.2005 08:57
Reason for closing:  Implemented in devel
Additional comments about closing:  

Mac says that it's done, and I believe him.

This sounds like a really good idea! The main reason for me choosing Flyspray was to manage dependancies. Being able to see a graph of dependencies sounds like exactly what we need.

Your suggestions as to how to achieve this, I must confess, went a little over my head, but I wholeheartedly approve of a system to graph and visually identify tasks and associated recursive dependencies. I tried using mind mapping in order to assist orgnaisation, but finally resorted to Flyspray, must confess I miss ze pictures!

Basically it comes down to a tradeoff between about three options:

1) Do our own layout, either using html/css, or a php image library like GD, to lay out the tasks in their dependancies. Upside: Simplest solution, works well in simple cases. Downside: it is very difficult to make a good algorithm that handles complex cases.

2) Use dot or vcg to do layout of the graph for us, either making an image for us, or giving us back a layout that we render with html/css or GD images. Upside: great layout algorithms for simple and complex dependancy graphs, about as simple to do as #1. Downside: requires additional software to be installed with flyspray.

3) Use the method from #2, but rather than making them install dot/vcg, use curl or xmlrpc to talk to a remote server that has the software installed, and provides a service to do layout for the graphs. I’d be more than happy to run a couple servers like that, and to make code available so others can as well. Upside: great algorithms, no extra software to install. Downside: depends on external servers to draw pictures, and it’s a more complex solution than #2.

It basically comes down to a choice of which weakness we most want to avoid: poor rendering of complex graphs (#1), extra software we need to install with flyspray (#2), or dependency on an internet connection to an external server (#3).

If nobody watching the task (Tony?) has other comments about it, I’m inclined to bring it up on the list, since #2 and #3 would affect all flyspray users, and significantly affect the installation process.

We would prefer to avoid the extra software install... and dependency on an internet connection to an external server... so I guess that means we are in favour of solution #1.

I guess that begs the question how complex are you talking about being unachievable?

Does anyone else have any preferences? Or is it just you and me, Mac Newbold?

I see that this task has now been assigned to you congrats... Which solution are you currently favouring?

Damon: there’s been a discussion going on on the mailing list where others have expressed preferences too, in case you want to check it out.

Method #1 could do well with very simple dependency graphs - probably anything less than 5 tasks would be reasonably decent. It would be more work than #2 in many ways, because you’d have to write your own rendering engine once you figured out where each node and edge should be drawn.

Method #2 is where we’re currently leaning, since I’ve implemented it. An example is attached. People are suggesting that during the installation process it can guess/search for dot, and prompt for a path if not found, or be disabled.

Method #3 is being discussed on the mailing list as an option that could be chosen during installation, where they can choose to have the graphs disabled, enabled with a local renderer, or enabled using a remote server to render the picture. A service already exists called WebDot that would allow the image to be rendered as simply as including an image from a remote web server.

Personally, I doubt #1 will happen. There’s just too much work and too little advantage. #2 works nicely, and #3 could be implemented without much more work. I favor the option of choosing method #2 or method #3 when you install or reconfigure your flyspray.

   depends_190.png (11 KiB)

I’m not sure if others can see the attached image, so here’s a link to it (or one like it):

Anonymous Submitter commented on 13.07.2005 11:29

Mac: all logged in users of this installation can view attachments, just so you know. :-)

Anonymous Submitter commented on 13.07.2005 12:11

Because of my preference for not adding dependencies, of course I will favour option #1. However, I agree that it would be tons of work, with no extra payoff. I trust Mac’s judgement about using option #2.

One thing I will mention is that this task will not make it into the 0.9.8 release. We already have a shortlist of tasks to do, and the release will never happen if we keep adding more. It’s great that this is a standalone script, as we can keep it seperate from the rest of the code until after the 0.9.8 release. I would like to see it in the 0.9.9 release for sure. Let’s get 0.9.8 out the door, and get Mac’s hard work in ASAP.

...and now, bedtime.

Here’s the patch and the new file that implement this functionality. Let me know what you think, and what changes should be made to improve it. (For those who haven’t been watching the mailing list, it’s got a great thread about this task.)

   task-dep-graphs.patch (5.7 KiB)
   depends.php (6.2 KiB)

Wrong version of depends.php. Here’s the better one.

   depends.php (6.7 KiB)

This seems to be done, so it will get closed. A new task  FS#612  has been opened for setting up WebDot for people who can’t use system() (like this installation) or people who can’t or don’t want to install dot.


Available keyboard shortcuts


Task Details

Task Editing