#314 Bug summaries are not updated
Closed: Fixed None Opened 12 years ago by kparal.

If a bug report changes its summary, it is not projected into our blockerbugs app. See https://bugzilla.redhat.com/show_bug.cgi?id=853609 vs http://qa.fedoraproject.org/blockerbugs/18/alpha


This has to do with how the synchronization algorithm works. It was designed to update only the bugs it needs to update and thus searches based on modification time for status, whiteboard and depends. Since none of those were changed, the bug wasn't flagged for update and the title doesn't changed.

This should be a pretty easy fix, I'll try to get it done in the next day or so.

Fixed in [log:@dd888b4ecb170434b57c85d67b009e07394aab76 dd888b4] - added title modification as trigger for pulling bug into sync. Fixes #314

Pushed to master, deployed as 0.1.1 on qa.fedoraproject.org

It will apply only for new summary changes, right? Bug 853609 summary won't be re-sync until new summary modification occurs? I don't see a problem with that, just making sure I understand why it is still out of sync.

Replying to [comment:3 kparal]:

It will apply only for new summary changes, right? Bug 853609 summary won't be re-sync until new summary modification occurs? I don't see a problem with that, just making sure I understand why it is still out of sync.

Yeah, I didn't even think about that. 853609 won't change until either a full sync is forced or the bug's whiteboard, title, dependson or status changes.

I'm changing the update script to add an option for full sync since I doubt that this will be the last time that we'll want to do one.

I've added an option for full sync to the db update script but I'm currently seeing problems with actually performing the full sync - RHBZ is currently returning 502 proxy errors on the full sync so it looks like that's not going to happen right now.

We do have the option of doing the full sync without too much trouble now, though.

This really needs to get done before the F19 testing phase gets started - the fix isn't very hard (small modification of the bugzilla query), so it shouldn't take long.

I have been unable to reproduce this in the current devel version of the blocker tracking app. It looks like the query was changed to detect summary changes and this bug wasn't updated - closing now.

Log in to comment on this ticket.

Metadata