Detect when remote Bugzilla bugs are duplicates and link to the duped-to bug instead

https://bugzilla.mozilla.org/show_bug.cgi?id=454993 is an example

The only real issue I've seen is that in some cases, Launchpad is linking to a dupe bug instead of the duped-to bug. That should be fixed.

Besides that, I don't see a problem, and Launchpad isn't in danger of getting banned on Mozilla's Bugzilla.

On 19 Sep 2010, at 03:19, Reed Loden <email address hidden> wrote:

> The only real issue I've seen is that in some cases, Launchpad is
> linking to a dupe bug instead of the duped-to bug. That should be fixed.
>
> Besides that, I don't see a problem, and Launchpad isn't in danger of
> getting banned on Mozilla's Bugzilla.

+1

This should be pretty easy to implement, at least for Bugzilla 3.4 (or 3.2 + Launchpad plugin).

Thanks for the bug report. I'm glad to hear we're not in danger of getting banned. Thanks for that update.

Since this is an easy fix, I'll get someone to look at this today or tomorrow and get the dupe link handling straightened out.

Cheers,
deryck

It'd certainly save us work if we did get banned! ;-)

Actually, the reason you noticed it last week is because we recently added the ability for launchpad to pull in the upstream bug Importance (aka priority/severity) values so distro engineers can better track upstream priorities, and that caused a one-day update of all bugs.

Reed panicked a bit seeing the branch I attached, so let me clarify.

There's actually two problems. The first is what this bug report was originally filed about - that checkwatches updates bugs that are dupes upstream. That's a straightforward problem to fix since we track the status and know that it's a dupe already at the point we update it.

But Reed updated the bug to focus on a more fundamental issue - that Launchpad does not automatically update bug watches when the upstream bug becomes a dupe. Presumably, if it did, it wouldn't even be trying to update the bugs to begin with. However, this is not a straightforward thing to fix, because we do not track the upstream duplicate bug number in the BugWatch table, or anywhere easy for checkwatches to find.

Anyway, the first is easy to fix and solves the original complaint so I did that. The other is going to require more thinking to figure out. I've emailed gmb to gain his wisdom, so we'll see. The trick is probably going to be whether Bugzilla gives us this info cheaply enough.

Here's the design we came up with:

For Bugzilla, when checkwatches does its bug updates, it checks if the watched bug is a dupe_of() something. As it runs across dupes, it stores in the launchpad database the fact that it's a duplicate, and what it's a duplicate of. A bugwatch is also created at this point for the newly found master bug, with its status/importance/etc. gathered.

In the BugWatch class, when the remotebug is requested, the code will note that the linked bugwatch is a dupe and switch it out for the master bug watch. So, in other words, internally we know what the original bug report was, but for all intents and purposes all users of remotebug will be looking only at the master bug.

The reason this approach is better than just changing out the bug link directly, is because sometimes bugs are duped incorrectly and later re-duped to other bugs, so this enables us to track and react to these changes. However, for all intents and purposes it LOOKS like we've changed the bug link.

In the UI, it'll be displaying just the master bug; no UI changes are needed here. (There is an open question about if users would want to be able to get to the original bug; we don't *think* they will, but if so then we'll need to figure out a UI for doing that.)

The LP API will also return the master bug the same way. We'll need to add a functionality to the API for getting the 'originalremotebug' or some such, in case scripts need to get to that.

In either the UI or API, if the remotebug is ever changed, both the original and master bugwatches are replaced by whatever the user specifies as the new watch.

We're looking at probably four branches for this feature:

 1. db patch to track dupe_of
 2. checkwatches capture dupe_of & create bugwatch
 3. make bugwatch switcharoo bugwatches
 4. update the api to switcharoo too & extra call to get original

As this is a non-trivial amount of work and I've already got plenty of irons in the fire on another project, I'm going to focus on that project. I may or may not have time to work on this after that project's done; if not someone else can pick this work up.

I think this would be most excellent to do. Given the raft of other bugwatch stuff that is currently outstanding, I'm downgrading it to low, but we would be delighted to mentor someone wanting to work on it.