Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Needinfo the author or reviewer for inactive revisions on Phabricator #2417

Open
wants to merge 19 commits into
base: master
Choose a base branch
from

Conversation

benjaminmah
Copy link
Contributor

@benjaminmah benjaminmah commented Jun 3, 2024

Resolves #1533.

Intended to:

  • Needinfo the author if the last action was by the reviewer
  • Needinfo the reviewer if the last action was by the author
  • Only needinfo if the revision state is needs-review

Checklist

  • Type annotations added to new functions
  • Docs added to functions touched in main classes
  • Dry-run produced the expected results
  • The to-be-announced tag added if this is worth announcing

@benjaminmah
Copy link
Contributor Author

Still a WIP!

@benjaminmah benjaminmah marked this pull request as ready for review July 3, 2024 20:41
@suhaibmujahid suhaibmujahid added the to-be-announced Improvements to be announced: send to dev-platform, firefox-dev and add to EE newsletter label Jul 8, 2024
@benjaminmah benjaminmah marked this pull request as draft July 9, 2024 14:14
@benjaminmah benjaminmah removed the request for review from suhaibmujahid July 9, 2024 14:16
@benjaminmah benjaminmah marked this pull request as ready for review July 9, 2024 19:36
@benjaminmah
Copy link
Contributor Author

@suhaibmujahid Since this PR introduces a new rule, would we have to update https://wiki.mozilla.org/BugBot?

@benjaminmah benjaminmah requested a review from marco-c July 23, 2024 19:45
@marco-c
Copy link
Contributor

marco-c commented Jul 24, 2024

@benjaminmah could you dry-run it and share the results?

@benjaminmah
Copy link
Contributor Author

@benjaminmah could you dry-run it and share the results?

Here are the results of the dry-run: dryrun.log

)
return response["data"]

def handle_bug(self, bug, data):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of querying bugs and then finding revisions attached to the bugs, we could search for revisions directly. WDYT @suhaibmujahid?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will need to query the bugs anyway to ensure we did not comment on them. All the queried bugs have attached revisions. Doing it the other way could be more efficient (not sure), but it will be a bit more complex since BzCleaner is designed to start from bugs.

@@ -0,0 +1,3 @@
:{{ nicknames }}, your patch is still waiting for action. Could you please address the feedback from the reviewer {%- if has_old_patch %} or consider abandoning the patch if it is no longer relevant {%- endif %}?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A problem I see with this is if the reviewer's last action is something like adding a comment saying "I'll get to this soon". I guess we have to accept this will never be entirely precise :)

@marco-c
Copy link
Contributor

marco-c commented Aug 5, 2024

I checked three random results from the dry-run and they looked OK. @benjaminmah could you double-check three random ones yourself too to make sure they look good? In case of any doubts, feel free to ask me or @suhaibmujahid for our input

@benjaminmah
Copy link
Contributor Author

I checked three random results from the dry-run and they looked OK. @benjaminmah could you double-check three random ones yourself too to make sure they look good? In case of any doubts, feel free to ask me or @suhaibmujahid for our input

Here are the results of the dry-run: results.log

Overall, the randomly selected results seem okay. However, as you mentioned in your other comment, there are a few cases where the reviewer/author leaves a comment without expecting a response (e.g. "Will work on this"). However, not sure if there is an easy way to identify these types of comments.

@marco-c
Copy link
Contributor

marco-c commented Aug 7, 2024

To be extra cautious, let's add a limit of 1 action per day so we can see the impact.
After Dublin, we can evaluate and remove the limit if all is good.

@benjaminmah
Copy link
Contributor Author

To be extra cautious, let's add a limit of 1 action per day so we can see the impact. After Dublin, we can evaluate and remove the limit if all is good.

I've enforced a limit for max_actions here: 3efbfd1

Let me know if this looks okay!

marco-c
marco-c previously approved these changes Aug 7, 2024
# You can obtain one at http://mozilla.org/MPL/2.0/.

import re
from typing import Dict, List
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let us use dect and list instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done here: 8172791

abandon the patch as an option.
patch_activity_months: Number of months since the last activity on the patch.
"""
super(InactiveRevision, self).__init__()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
super(InactiveRevision, self).__init__()
super().__init__()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All other rules in BugBot include the rule name and self, so I was thinking we could keep it as it is for consistency. Please let me know if you think otherwise and I can go ahead with this change.

for _rev_ids in Connection.chunks(rev_ids, PHAB_CHUNK_SIZE):
for revision in self._fetch_revisions(_rev_ids):
if (
len(revision["attachments"]["reviewers"]["reviewers"]) == 0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there is no reviewer, we may still want to notify the author.

Comment on lines 186 to 189
if (
last_transaction
and last_transaction["dateCreated"] < self.patch_activity_limit
):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be more explicit if you flip the condition and use continue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Done here: 69385c6.

Comment on lines +307 to +312
if comment["creator"] == History.BOT and comment["raw_text"].startswith(
"The following patch"
):
rev_ids_with_ni.update(
int(id) for id in PHAB_TABLE_PAT.findall(comment["raw_text"])
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This matches comments from the 'inactive_reviewer' rule, but not from this rule. Also, we do not list patch IDs in the needinfo comments, so this is not going to work.

)
return response["data"]

def handle_bug(self, bug, data):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will need to query the bugs anyway to ensure we did not comment on them. All the queried bugs have attached revisions. Doing it the other way could be more efficient (not sure), but it will be a bit more complex since BzCleaner is designed to start from bugs.

Copy link
Member

@suhaibmujahid suhaibmujahid Aug 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a substantial amount of duplicated code from the inactive_reviewer rule.

Here are some potential solutions to mitigate the issues:

  • Using a superclass to host the common logic
  • Merge the two rules into one
  • Create some util functions

This applies to #2426 as well.

@marco-c wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I vote for the third option (create some util functions) or the second (merge the two rules into one).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, I think creating util functions will reduce duplicate code while still keeping the rule separate. Similar to the no_severity rule, the first step could be to needinfo the pending needinfo'er (which could be the reviewer or author) and the second step could be to unblock bugs and find an active reviewer. Of course, these would be separate rules to avoid having complex multi-step rules similar to no_severity. WDYT?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
to-be-announced Improvements to be announced: send to dev-platform, firefox-dev and add to EE newsletter
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Detect inactive revisions on Phabricator
3 participants