Bug Relationships

[Roscio, Steve]

I think this is a good idea.  We use Bugzilla to hold our requirements, user stories, sprint tasks, etc in addition to the bug-side of things.  I could see this used to indicate which tasks are derived from what stories/requirements, and so on.  Right now we just use "depends" and then add extra keywords to tag what things are.  For regressions, we don't use 'depends'/'blocks' because it breaks the other kind of dependencies we do.  So this idea -- typed dependencies -- would be useful to my team.  FWIW.

- Steve

-----Original Message-----
From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Gervase Markham
Sent: Monday, January 11, 2010 10:30 AM
To: dev-apps-bugzilla at lists.mozilla.org
Subject: Bug Relationships

[I've had this idea kicking around in my head for a while, but I don't
think I've ever written it up properly for discussion. So here it is.
It's inspired by a feature on a proprietary bug tracking system I used
to use. It was generally terrible, but this was good.]

I think that we should replace dependencies, See Also, and perhaps
duplicate marking too with a more generic system of Bug Relationships.

It would work like this: an admin would define a number of relationships
there could be between bugs. (Some common ones would ship by default.) E.g.

A depends on B
C caused regression D
E is the upstream of F
G is a duplicate of H

And, of course, the reciprocal language for each relationship would also
be defined, if different:

B blocks A
D is a regression from C
F is the downstream of E
H is a duplicate of G


Then, you would have UI on a bug like this:

This bug [  blocks   |V]  [        ]

where you would select a relationship, and then enter a bug number or a
URL to a bug in another bug system (Bugzilla or otherwise) in the text
box. (Or a comma/space separated list.) If you entered a bug number in
the same Bugzilla (and even maybe, one day, with APIs, in other
systems), the other bug would display the reciprocal relationship.

This has several advantages:

* It allows sites to codify things like "bug A is a regression from bug
B" rather than what e.g. b.m.o does now, which is have a "regression"
keyword, and then perhaps abuse dependencies. This might allow the
gathering of stats showing things like "ooh, look, 50% of our
regressions come from bugs fixed by Fred".

* It simplifies the UI on the bug page. Instead of UI for depends,
blocks and See Also, plus any custom fields a site might add (remember,
Bug ID is a custom field type), we just have the above selector, plus
editable details of existing relationships (which in many cases, will be
none, so the common case is simpler).

* It allows one to be more specific than "See Also", where each user has
to load up the bugs in the list and work out what the relationship is
and whether it's relevant to them. More useful semantic information is
captured.

So as I see it, it's a generalization which brings more power and makes
things simpler, without losing any functionality.

What do people think?

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=Steve.Roscio@hp.com>