1031867 - Repo tab titles should show the number of unclassified failures in the current view, not the current week

Status: RESOLVED FIXED

(Tree Management :: Treeherder, defect, P1)

Description

[Phil Ringnalda (:philor)]

For non-try trees, showing the number for the current week merely makes it unusable: while we may claim that every failure should be marked, we don't do it, and if on Monday morning I load treeherder, deal with the visible failures in the last 10 or 20 pushes, and am then told that there are 700 more failures going back to Friday night... I don't care, and telling me just makes the number useless, because it cannot tell me at a glance whether there are 7 more in my visible view since I last looked, that I'm going to deal with. For try trees, where tbpl tells me how many are unstarred in my try push, and treeherder tells me nothing, it's a loss of a valuable feature.

Comment 1

[Ed Morley [:emorley]]

Yeah I think we should switch back to this in hindsight.
We can always use a separate "show unclassified failures" view that allows filing of bugs and sifting through yet to be classified failures on mass.

If we do switch back, it would mean that we don't really have any count to show for pinned repos that aren't currently being displayed, which factors into bug 1032220 too.

Comment 2

[Cameron Dawson [:camd]]

I've implemented this change in my current branch.  However, I'm wondering if there may be some value to keeping a view into the unclassified failures beyond what is currently showing on the page.  Perhaps a shorter time window like the last 24 hours?  Last 12?  Last 8?  The original thought had been to tip the sheriffs off that there's something to look for there.  Perhaps you could see two numbers.  <count loaded>/<last 8 hours> or something like that.

Dunno.  Just trying to prevent us throwing the baby out with the bath water.  Unless, of course we really don't like that baby...  :)

Comment 3

[Phil Ringnalda (:philor)]

I tried to reproduce that theoretical workflow, by loading the six repos I watch, then noting that there were 4443 unstarred failures on mozilla-inbound for the week, that I was supposed to deal with. So I prepared to load a week's worth by clicking the get next 100 button. It only gives me "Error retrieving job data!". Loading by 50s, I was able to get back to last Thursday, at the cost of a screaming fan, and multiple unresponsive script dialogs per load, and beachballing and laggy scrolling toward the end. That weeklong dog won't hunt.

My workflow is to sleep the computer with what I was looking at, wake it and have tbpl load from there to the tip, deal with whatever's left unstarred (to the extent I want to), then reload to get back to the active pushes, but the way other people clearly don't do that, and only look at the tip 10 at the time they wake up, does show a need for something like this, if we can't persuade them to do the right thing instead. My real goal for this bug was to angle toward tbpl's one-repo-per-tab with the live unstarred count for the current view in the tab title, because that's key to my workflow, so having a total for a more reasonable, loadable (I just had to stop and kill the treeherder tab with 4.5 days of m-i in it, to be able to continue typing this) period like 24 hours somewhere other than where I'll be angling to get it into the tab title wouldn't bother me in the least.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

(In reply to Phil Ringnalda (:philor) from comment #3)
> but
> the way other people clearly don't do that, and only look at the tip 10 at
> the time they wake up

Not everyone does this, FWIW ;)

Comment 5

[Ed Morley [:emorley]]

(In reply to Cameron Dawson [:camd] from comment #2)
> I've implemented this change in my current branch.  However, I'm wondering
> if there may be some value to keeping a view into the unclassified failures
> beyond what is currently showing on the page.

Perhaps we could add it to the future feature of a classification mode, which shows all "new intermittent yet to be classified" type failures as well as anything leftover from weekends etc?

Comment 6

[Cameron Dawson [:camd]]

I pushed some of these changes to treeherder-dev.allizom.org today:

* count for each watched repo is unclassified failures over the last 24 hours
* count on the currently loaded repo (and in the window title) is unclassified failures that are currently loaded

We clearly still have some performance issues we're attempting to fix (loading 100 resultsets at a time is a no-go, atm).

Comment 7

[Ed Morley [:emorley]]

(Changing status to assigned, so it displays in the correct colour on the new bug tables on the treeherder wiki page)

Comment 8

[Cameron Dawson [:camd]]

Attachment: pull request

Comment 9

[Cameron Dawson [:camd]]

Latest commit with these fixes: https://github.com/mozilla/treeherder-ui/commit/685f661d2b2980560cc31c8c0579d8e13380b943

Sorry I didn't follow the requested process on this.  I had done these changes just prior to Ed's email.  But I'm trying to get as close as possible now.

Comment 10

[Cameron Dawson [:camd]]

These changes are pushed to Stage and Production.  Please have a look and see if they address the concerns in this bug.  If not, let's iterate on this and get it right.

Comment 11

[Ed Morley [:emorley]]

(Setting needinfo flag on me to add this to my queue; if you have a question that needs a response - using needinfo will make sure I don't miss it :-))

Comment 12

[Ed Morley [:emorley]]

lgtm, thank you