It seems like it's not widely used and may be causing some problems. At the same time there's a considerable refactor going on to improve the reliability and responsiveness of the feature, so turning it back on by default once that's deployed might make more sense.
Created attachment 8803933 [details] [review] [treeherder] mozilla:autoclassification_disable > mozilla:master
Attachment #8803933 - Flags: review?(wkocher)
Comment on attachment 8803933 [details] [review] [treeherder] mozilla:autoclassification_disable > mozilla:master R+, though I'm curious if that herokuapp condition is still useful now that everything's on heroku (we have "&autoclassify" to turn it on and "&noautoclassify" to turn it off).
Attachment #8803933 - Flags: review?(wkocher) → review+
Only treeherder-prototype is typically used through the herokuapp domain, so that's the only case where it applies. I'd still like this stuff on on prototype by default unless we figure out some method of getting private instances with prod data.
Commit pushed to master at https://github.com/mozilla/treeherder https://github.com/mozilla/treeherder/commit/e720b42af89b6db9cf504da1059c1ee916b897d0 Bug 1312459 - Disable autoclassify panel by default (#1948) Adding &autoclassify to the url still allows it to be enabled. This will allow the feature to be refactored rather than spending lots of time investigating sub-issues in the current implementation.
Assignee: nobody → james
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.