[Development] RFC: New keyword for Fixes bot "Reopens" and revert detection

Volker Hilsheimer volker.hilsheimer at qt.io
Mon Apr 15 16:49:26 CEST 2024



On 15 Apr 2024, at 12:36, Tor Arne Vestbø via Development <development at qt-project.org> wrote:



On 15 Apr 2024, at 12:07, Daniel Smith via Development <development at qt-project.org> wrote:

I'd like to open up a thread for discussion on the addition of a new commit message footer, "Reopens", related to Fixes/Task-Number.

The proposed behaviour is:

  *
Use of "Reopens: QTBUG1234" would trigger automatic reopening of the specified jira issue upon uploading a new change to codereview.
  *
Jira issues specifying Reopens would be tagged with the merged sha of the change.
  *
Issues specifying Reopens can be automatically closed by also specifying "Fixes" as usual.
     *
The Jira Closer Bot has traditionally refused to close issues which is has previously closed. Including Reopens would bypass this check and allow the issue to be closed with the presence of Fixes.

Is this really such an often occurrence that we need a keyword for it? If you know that it invalidates a fix for an existing QTBUG, re-opening manually seems like a pretty small task.

For reverts of commits with “Fixes” in them it should be fine to re-open the bug. And to close it again once a new commit lands with Fixes.  The bot should be able to tell by the “author” of the status change in JIRA if it’s okey to re-close it, no?

Is the motivation here primarily to allow the bot to re-close the issue later on, even for non-reverts changes? How about we just trust the “Fixes” in the change, and close the issue, even if it was previously re-opened?

Cheers,
Tor Arne


The difference between a new “Reopens:” footer and a manual reopening is that code review can catch and look out for the former, but not the latter. So that’s good: if we know that a reverting patch brings back the bug, then we want to make sure that the ticket gets reopened again. And if we don’t know, then the committer explicitly pointing out that by reverting this change we might bring back what might be a nasty bug might be useful information.

This could even be caught by a sanity bot - not as a -1, but as a note pointing out that the commit reverts a change that previously closed a ticket, hinting that perhaps the ticket should be reopened.

So I think this addition would be a useful workflow improvement.

Volker


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240415/b1a6a3e4/attachment.htm>


More information about the Development mailing list