853479 - Adding a local bug to the see-also field creates a backlink in the other bug's see-also field.

Status: NEW

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Philip Chee]

After Bugzilla was updated to v4.2 adding a local bug to the see-also field automatically creates a backlink in the other bug back to mine. This led to a add/remove war with the reporter in the other bug who didn't want to be linked to my bug. This is extremely annoying. Also the whole idea of the see-also field was so that people could stop abusing the Blocks/Depends fields. Mandatory creating backlinks thus defeats the raison d'etre.

Comment 1

[Thomas D. (:thomas8)]

(In reply to Philip Chee from comment #0)
> After Bugzilla was updated to v4.2 adding a local bug to the see-also field
> automatically creates a backlink in the other bug back to mine. This led to
> a add/remove war with the reporter in the other bug who didn't want to be
> linked to my bug.

Can you provide the bug numbers where this happened so that we can look at a real-life scenario? When the reporter of the other bug removed the see-also from "his" bug, was he aware that as of 4.2, see-also links behave reciprocally, i.e. that he was concurrently going to remove the see-also link from "your" bug, too?

Comment 2

[rsx11m]

That happens frequently when you want to establish a weak dependency, e.g., from an application-specific bug to a general Core bug. An example is my bug 845353 for SeaMonkey which resulted from bug 818340 and needs to be followed-up upon by any changes coming with bug 851606.

It's of not much interest for the people following bug 818340 that we needed to make follow-up changes in SeaMonkey, thus a reference in a single direction would be appropriate (that was a change in the past which is now followed up upon by the specific application). With bug 851606, it may be a different story as whoever is proposing/making changes there on a short term should be aware if and how this may affect applications to avoid catching them by surprise late in the cycle.

I didn't have a problem with the reporter of either bug, but removed the "See also" dependency for 818340 immediately after seeing that it was bidirectional.

I agree with Phil that both unidirectional and bidirectional relationships should be possible to cover specific cases. Maybe default to creating a counter-link but provide a checkbox when editing that field which one can uncheck to avoid that?

Comment 3

[rsx11m]

(In reply to Thomas D. from comment #1)
> Can you provide the bug numbers where this happened so that we can look at a
> real-life scenario?

One example I've observer was bug 847546 (SeaMonkey) vs. bug 849460 (Core), which is very similar to the scenario I have encountered.

> When the reporter of the other bug removed the see-also from "his" bug, was he
> aware that as of 4.2, see-also links behave reciprocally [...]?

No discussion past bug 849460 comment #2.

Comment 4

[Frédéric Buclin]

The reporter shouldn't be allowed to edit URLs in the see also field, unless he has editbugs privs.

Comment 5

[rsx11m]

Frédéric, I don't think that's the issue here. Both Phil and myself have editbugs privs, so that's not the problem. My checkbox proposal in comment #2 would simply make the reverse link optional rather than mandatory, thus covering both "see also" aspects.