search

mozilla-services / updatebot

Automation for updating third party libraries for Firefox
Mozilla Public License 2.0
8 stars 5 forks source link

Better logic about when to close bugs as duplicates #311

Open tomrittervg opened 1 year ago

tomrittervg commented 1 year ago

Iain suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=1805798#c12 to not close a bug as a dupe if it has new patches attached.

Background: Presently if there's a new library version available, Updatebot will close the last bug it opened as a duplicate and forward you to the new bug it has just filed. When it does this, it will mark the bug it just closed as 'relinquished' in its database, which means it will never attempt to close the bug again. This is to prevent it from getting into close-reopen fights with developers. (The idea being if it shouldn't have closed it, the dev will re-open it, and Updatebot will not touch it again.)

It wouldn't be too hard to add in some logic there to not close it as a dupe if e.g. there are new patches attached or some other criteria. Along with that, Updatebot should still mark it as relinquished - if Updatebot sees activity that means it shouldn't close it now, then it shouldn't close it in the future.

However the harder part is what should Updatebot do with the new bug? It could file it as usual and set it as a 'See Also'. Or as a Dependency (i.e. close out the bug you're working on, and now go fix this new one I filed.) It could also add a comment to the bug saying "I'm not going to file a new bug because it seems like you're working on this one, but I would have."

I think filing the new bug and setting it as a Dep makes the most sense to me?

rvandermeulen commented 1 year ago

I like the "I would have filed a bug" comment personally.

iainireland commented 1 year ago

I also like the "I would have filed a bug" comment. Two corner cases to consider:

  1. Somebody attaches a patch to a bug, then forgets about it. It would be bad if this completely turned off updatebot for this dependency. New bugs are less likely to fly under the radar than new comments, but new comments are still probably loud enough. (Not sure if there are any users of updatebot in under-supported components where one person leaving the company might mean nobody gets bugmail.)
  2. If the patches on the older bug are based on a stale version of upstream, then there might be changes in the new updatebot bug that aren't included in the human-authored patches on the old bug. In theory we could maybe detect that by running updatebot on top of the attached patches, but that seems complicated and in practice it's presumably fine to just let those changes wait until after the current patches land.
tomrittervg commented 1 year ago

Somebody attaches a patch to a bug, then forgets about it. It would be bad if this completely turned off updatebot for this dependency. New bugs are less likely to fly under the radar than new comments, but new comments are still probably loud enough. (Not sure if there are any users of updatebot in under-supported components where one person leaving the company might mean nobody gets bugmail.)

I am going to regret this when I have to add in all this logic, but I think to combat this, if there are patches and the bug is open but no activity in a bug for 10(?) days - then Updatebot will not leave a comment; but will rather file a new bug...