Trac status of "Verified" confuses bug watcher

[Jim Nelson]

We use in our bug process a "verified" status which indicates that the fixed & closed bug is indeed fixed. When the Trac bug watcher sees this, it moves the Launchpad bug to an Unknown status.

[Gavin Panella (allenap)]

Jim, is "verified" an out-of-the-box status value in Trac, or is it something that you've added for your project? If the latter, is that done by hacking the Trac code, or are custom statuses supported natively by Trac?

[Jim Nelson (yorba-jim)]

"Verified" is something we added for our purposes. We didn't have to hack Trac, adding custom statuses are supported.

[Gavin Panella (allenap)]

Okay. We have custom mappings for some other bug trackers so I guess we can add support for this.

To me, before I read further, "verified" seemed to be a parallel to Launchpad's "Confirmed" status, so I don't think we should add it as a general Trac->Launchpad mapping. We should probably add it as a custom mapping for this particular bug tracker.

Jim, what's the URL for your bug tracker (or its page in Launchpad)?

[Gavin Panella (allenap)]

Ah, found it: http://trac.yorba.org/

[Jim Nelson (yorba-jim)]

I'm not sure Verified matches Launchpad's Confirmed status -- we use Verified to mean the fix has been verified, not that we've reproduced the problem.

[Deryck Hodge (deryck)]

Jim, would you be willing to rename verified on your end to something like fixverified? I think what Gavin is getting at is that if we blindly map verified to fixed, then another trac might use verified to me something more like our confirmed.

[Jim Nelson (yorba-jim)]

I see -- yes, I think we could do that. Let me check with Adam and verify (ha-ha) that's okay with him.

[Gavin Panella (allenap)]

We can also add a specific mapping for trac.yorba.org so that you can keep verified as it is. It's less generally useful, but we do it already for other trackers.

[Vera Yin (vera-yorba)]

The resolution "verified" has been renamed "fixverified" at http://trac.yorba.org and tickets previously marked as "verified" have now been updated to reflect that.

[Gavin Panella (allenap)]

I assume we'll map "fixverified" to "Fix Released" on Launchpad. Let
me know if that isn't what you expect.

Bumping this to High to keep the momentum.

[Jim Nelson (yorba-jim)]

That makes sense.

[Launchpad QA Bot (lpqabot)]

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

[Gavin Panella (allenap)]

I have absolutely no clue how this could have broken in QA. I'll get
some other eyes on this in the morning.

Log from qastaging: https://pastebin.canonical.com/39679/

[Gavin Panella (allenap)]

This hasn't caused any regressions as far as I can tell, so I've
marked it as qa-ok while continuing to bash my head against the wall
trying to figure it out :)

[Gavin Panella (allenap)]

There seems to be a complication where staging code is being run even
when invoking scripts in the qastaging branch; see lines 1 and 48 in
the earlier paste. Chex will look into it next week (he is way too
busy this week because the other LOSAs are otherwise engaged).

I will mark this as qa-untestable. I am confident that this fix will
not introduce any regressions. In fact, I'm confident that this branch
will work as intended.

Phew, what fun :)

[Gavin Panella (allenap)]

This seems to be working correctly.