Automatically handle moving duplicates across when duplicating a bug with dupes

This is important; see bug 14911 for one of many examples of people not bothering with otherwise-obvious gardening because this is so inconvenient. This makes it unnecessarily complex to garden duplicates for often-duplicated bugs, which are the ones which need it most.

Duplicates are lossy: as the chain lengths -- B1 is a duplicate of B2, which is a duplicate of ... Bn -- the greater the probability that B1 will not actually be a duplicate of Bn. Therefore I suggest listing the summary of each of the bug reports that is about to be indirectly marked as a duplicate. "Marking bug 62988 as a duplicate will also mark these bug reports as duplicates. If any are not actually duplicates, uncheck them:"

Fixing this bug would make bug 77908 irrelevant

I'll duplicate (pardon the pun) the essentials of my suggestion from the duplicate bug 253345 here. Keeping the bug report CHAINS intact (as I have suggested) could at least partly address Matthew Paul Thomas's legitimate concern about lossy duplicate relations:

*

Moreover, if such chains of duplicates were managed, AND if the original duplicate relation were kept (and if it were even possible, after going through a warning, to mark a report as a duplicate of a duplicate (due to the reports being virtually identical)), it would allow reports to be grouped based first on identical symptoms and second based on the identified root cause.

Let me illustrate with a diagram:
"->" indicates duplicate relationship, "*X*" indicates a master report.

Practically identical bugs
A -> *B*

Other bugs, different symptoms
C -> *D*

Further duplicate management to master report *G* that discusses the root cause of why A, B and on the other hand C and D are occurring in the first place, and the fixing of which will allow closing bugs A, B, C and D as well:
A -> B \
---------> master report *G*
C -> D /

If a duplicate status is later found wrong (the root cause for bug A and bug B wasn't, after all, bug G), un-duplicating a GROUP of reports at once, WHILE maintaining the duplicate status WITHIN that group (keeping bug A as a duplicate of B), would allow more flexible duplicate management also in a case like this.

A note on the UI:

I believe a way could be found to nicely show the grouping of duplicates in the master report. Perhaps a slightly indented multi-level bullets list instead of the current single-level list.

I have also come across the "mark all dupes as dupes of another" problem. It's very fiddly trying to unmark dupes and reset them as dupes of another as one that might have been missed might have more relevant information than the rest, and having to go and unmark them all (which can be difficult to find how to do it) is tiresome at times.
I'd appreciate if there were a fix for this at some point, but for now there is a way to do it, even if it is long.
Teej
Ubuntu Bug Control Team

in the meantime this would be a good solution (afflux pointed it to me at irc, thks!)

If you have python-launchpad-bugs installed, /usr/share/doc/python-launchpad-bugs/examples/move_duplicates.py may be what you need

just to be sure that i get the A/B/X/Y/Z-terminology right:

if i think it is troublesome to merge two bugs that both have duplicates[*] - is this the right bug report then?

[*] because i have to manually move away the "children" of one bug before i can mark this bug as duplicate

Michael Nagel: Yes, you are in the right place. :-)

meant to say also affects o-s-g, not change assignee.

from the activity log it looks to me that this bug was not assigned to anyone before I erroneously assigned to "malone'. So I am setting it back to unassigned.

When you click on the "Mark as duplicate" link of a bug with duplicates, you end up with a not-at-all-nice traceback inside the little ajaxy window (screenshot attached).

I think the link should not be shown if it's going to traceback and cascading the duplication is problematic.

It may be that the detection cost is high enough that we don't want to do it for every rendering of the bug, but are willing to do it when the "Mark as duplicate" action is taken. However, we could still avoid showing the full traceback, which is fairly useless (unlike the message that precedes the traceback, which is useful at least until this bug is fixed).

Actually, one option would be to replace the traceback with a link to this bug! (Again, until this bug is fixed.)

By the way, John, if you feel strongly enough about it you can help fix this bug. See https://dev.launchpad.net/Help for how; the code is open-source, and existing developers are very happy to help potential contributors learn their way around.

The traceback shown in the ajax widget is bug 365620

Fixed in stable r11188 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/11188>.

This works on staging, though it was a bit prone to timeout. After a couple tries, the operation would succeed, so I suspect once postgres cache was warm, we're good. I'm marking this qa-ok since otherwise it works well, and I will begin working on a branch to ease timeout potential now, which can be CP'ed to production after the 10.08 rollout.

The timeout potential comes from doing all the subscriber notification work in app, rather than offline. This should be changed anyway and will help other areas of the site. But it's a big change and I don't want to block this work on it.

Cheers,
deryck