Re: [Fresco-devel] Explanation of relation between bugs/tasks? (in issues.f.o)

Hi Nathaniel,

Nathaniel Smith wrote:
> Stefan (or anyone else), can we get a description of the intended use
> of bugs vs. tasks?  I keep running into weird little quirks that might
> make more sense if I had a coherent model -- like, it's annoying that
> I can't get a single list of all bugs and tasks assigned to me, and I
> don't understand the logic about what can depend on what, and so on.
> What are the possible relations between bugs and tasks supposed to
> look like?  How are these supposed to be coded in Roundup's dependson,
> supersededby, etc. fields?

glad you ask !

I sent a mail some days ago where I requested feedback about these
very questions. I don't have the answer. The question is really how
we (the team) *want* to use these issues, i.e. we adapt roundup to
match our idea of an (open) development process.

A bug is a specific failure in our components, which can be reported
by a user who runs into it. Thus the 'bug' entity will help track us
the processing of the report, i.e. probably the work necessary to
fix it.

On the other hand, a task is a process, more in line with 'research &
development', i.e. something that is better addressed in terms of an
activity.

I see both entities as somewhat orthogonal, though a number of relations
may exist between them, such as 'task foo solves bug bar'.
Bugs may depend on other bugs, i.e. a specific bug fix may require
another bug to be fixed. Same with tasks, a task may depend on the
outcome of another task.

As to 'superseded', that's a generic way to describe abrupt changes
in a bug's/task's lifecycle, with parent/child kind of relationships.
You can merge or split these issues, can declare one bug as a dup
of another. In all these cases 'superseded' would be useful (may be
with an additional 'relationship type' fields, but that may already
be overkill...

I would try to keep the schema as simple as possible, as in 90% of
the cases these relations are sufficient. Can you describe a typical
situation where a task depends on a bug ? Would it be possible to
describe such a situation with the above relations ('task foo solves
bug bar that depends on bug baz', say) ?

Anyway, any suggestions to enhance our issue tracker are more than welcome.

Regards,
		Stefan