Use a directed acyclic graph to control the order of execution within and among deployment stages.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
I agree that within stages a DAG would be awesome to have. What worries me here is to use one for defining the relationship between stages as well. What would be the rationale for that?
My fear is that we would end up with a Puppet-like system, which, precisely because of the extensive usage of DAGs, makes it quite hard to get right from the start and reason about since a lot of processes may happen in parallel.
Comment Actions
This will be a lot simpler than puppet. And 'among stages' probably doesn't need to use a graph resolver.
You can see what I have so far in {D76}
Comment Actions
@mmodell: The previous comments don't explain what/who exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status.
(Smallprint, as general orientation for task management: If work on this task is blocked by another task, then that other task should be added via Edit Related Tasks... → Edit Subtasks. If this task is stalled on an upstream project, then the Upstream tag should be added. If this task requires info from the task reporter, then there should be instructions which info is needed. If you wanted to express that nobody is currently working on this task, then the assignee should be removed and/or priority could be lowered instead. If this task is out of scope and nobody should ever work on this, then task status should be "declined".)
Comment Actions
this is obsolete, though it's still a good idea it's no longer relevant to current plans.