465534 - Cloning dependency relationship between new/old bugs seems backwards

Status: NEW

(Bugzilla :: Extension Ideas, defect)

Description

[Jim Arnold]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Build Identifier: 3.0.2

I often manage bugs that affect several components/developers.
So I create a base bug and then clone it several times:
-  create 'base'
-  clone base to c-1
-  clone base to c-2
-  clone base to c-3, etc.
The dependency relationships between the base the clones
seems backwards.  The base is marked as blocking all the
clones, and each clone is marked as depending on the base.

It would be more useful to reverse these relationships.
I think of the base as the 'umbrella' bug that needs all
its clones to be completed.  It depends on those clones
before it can be finished.  And each of the clones blocks
the base.

The depends/blocks relationships can be 'corrected' after
the bugs are created, but that is very tedious.

Another issue.  One could treat the last clone as the umbrella.
-  create base
-  clone base to c-1
-  clone c-1 to c-2
-  clone c-2 to c-3
...
-  treat last c-x as umbrella.

This creates an artificial sequential relationship,
which doesn't really suit the need.  Reversing the
depends/blocks relationship seems better.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Max Kanat-Alexander]

This is really hard to say--different use cases have different purposes, here.

Comment 2

[Frédéric Buclin]

(In reply to comment #1)
> This is really hard to say--different use cases have different purposes, here.

Which is why I didn't confirm this bug. IMO, if we reverse this behavior, the other half of users will complain that the other way to do it is also backwards. See, even the Bugzilla and Firefox teams do not use dependencies the same way when talking about regressions. Imagine how opinions may differ with different organisations.

Comment 3

[Jim Arnold]

I'll make one more observation and then let this go.

The current behavior sets the last (newest) clone as the
'blocked' bug.  It depends on its predecessor, and the
predecessor blocks the newest clone.  Because the newest bug's
number is unknown before it is created, multiple predecessors
cannot directly link to that last bug.  It is impossible to
create an 'umbrella' bug without manually setting the
depends/blocks fields.

Reversing the dependency relationship continues to support the
current behavior.  The dependency chain would run the other
direction, but the end result is equivalent.  The new
behavior additionally supports automatic 'umbrella' creation.
The first bug is the base (umbrella), it depends on the clones
created from it, and the clones are marked as blocking the
umbrella.

Summary:  Changing the direction of the dependency chain does
not remove existing functionality, and it adds something useful.

Comment 4

[Albert Ting]

Rather than changing the direction, how about making it a user preference?  In my company, I'm seeing both requests and it would be trivial to add a user preference.

Comment 5

[Albert Ting]

(In reply to comment #4)
> Rather than changing the direction, how about making it a user preference?  In
> my company, I'm seeing both requests and it would be trivial to add a user
> preference.

And perhaps combine this issue with bug 428102

Comment 6

[Albert Ting]

Attachment: v1

Attached is a 3.2 patch.  Would this suffice?

Comment 7

[Max Kanat-Alexander]

Comment on attachment 355534 [details] [diff] [review]
v1

I'm sorry, I thought I'd already said this in the bug, but I guess not. We're not going to add a user preference just for this. You could implement it as a plugin, though, perhaps?

Comment 8

[u430950]

Marking bug as potential extension.