Sheriffbot needs to rate limit itself when doing Available re-circulation |
|||||||
Issue descriptionSheriffbot-Auto-triage Rule: Available (re-circulation) bugs which are not modified for a year: Add Bug number which got updated (in a single day, so far): 18257 18823 19119 19875 19792 21774 22518 22964 23509 23556 23573 24011 24713 24831 25042 25943 25848 26393 26620 26685 26984 27061 28275 28300 28327 28413 28480 28481 Issue/Concern or feedback: Sheriffbot is providing some value by bumping old bugs that have been marked as Available and sending them back to Untraiged; I've been able to close out several as WontFix. But the volume of bugs that it is dredging up is way to high. The list of bug numbers above is from things just modified *TODAY*. Over the past few days, the triage queue the Mac team uses has been inflated from our normal number of ~10 to over 100! That's ridiculous and counter-productive to triage. It is not realisitic to expect us to triage that many bugs and to keep piling on about 20/day more. I think sheriffbot needs to limit itself to about a few bugs a day (<10), otherwise the volume is just too high to manage. While this is implemented, can we please disable this aspect? Any other important details:
,
Jun 28 2016
Is there a way to know how many bugs it's going to continue to affect, so that we can calculate the number/day and for how long we'll be at that rate? Cutting in half would definitely be a big help, though it may still be too many. Could we get that implemented today?
,
Jun 28 2016
,
Jun 28 2016
I don't think that cutting it in half solves the problem, but agreed that it's a reasonable place to start. We should be smarter about checking the owners of bugs or components we're updating.
,
Jun 28 2016
The cl to change the bug update threshold limit to 125 is landed/deployed.
,
Jun 28 2016
For personal triage (not bug rotations though), I think it'd also help a lot if the sheriffbot bugs didn't arrive in one big chunk around 9am EST but were spread out a bit more.
,
Jul 8 2016
Can we update the rules so that a bug that has been resurrected won't be resurrected again in about a year? Many of the bugs being dredged up were correctly available, Pri-3 feature requests. They were correctly triaged the first time. And the second time.
,
Jul 11 2016
Part of the intent for annual check-ins, is that often times issues lose relevance as they age. Perhaps the right answer here is to have some form of annotation (for example a label that could be applied) that the bugs shouldn't expire.
,
Jul 14 2016
The fact that we're doing everything in a large batch once per day is also causing some issues with how hard we're hitting the Monorail API, so I'm going to try to solve this in a more generic way by spreading out our requests.
,
Oct 27 2016
,
Jul 11
Bulk edit: archiving a few bugs assigned to me that no longer seem relevant. Please reopen if this is still something you'd like to see fixed and I'll re-evaluate it. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by lafo...@chromium.org
, Jun 28 2016