User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040209 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040209 When a bug (#x) has a dependency on another bug (#y) and then #y is marked as a duplicate (#z), the (#z) bug should also end up in the dependency list of the parent bug (#x) Reproducible: Always Steps to Reproduce: 1. enter a bug (#x) 2. enter a bug that block #x, say number #y 3. enter a 3rd bug (#z) 4. resolve #y by marking it a duplicate of #z Actual Results: #z is nowhere to be seen in the dependency tree of #x although #x will probably never be solved without solving #z (supposing that #y really blocked #x) Expected Results: My idea is that #z should have replaced #y in the dependency-tree of #x I found this problem on a locally installed 2.17.6 install, but trying it on landfill (2.17.7, see URL) showed that it is still not solved
That's not always correct behavior. And in fact doing it for high profile bugs can result in huge messes when errors in resolution occur. Better behavior would be for the verfication process to offer to copy over dependencies.
Summary: Duplicate of dependency bugs not handled → Duplicate of dependency bugs not handled
This adding of an option to copy the dependencies would indeed be ok. To make this conceptually more understandable it would maybe even be easier to add a REPLACED resolution type. So instead of having to mark a bug as resolved, duplicate of #y, there would be a radio-box option for the commit that says 'Replace with bug #z'. There still needs to be a link between bugs #y and #z though. (such that when looking at bug #z, a single click will lead to bug #y to potentially look at bug #y's history)
This looks a lot like bug #9403
*** This bug has been marked as a duplicate of 9403 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.