Closed Bug 1060456 Opened 10 years ago Closed 9 years ago

Job details: Tweak job attribute labels & ordering

Categories

(Tree Management :: Treeherder, defect, P4)

defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: emorley, Unassigned, Mentored)

Details

(Keywords: regression)

User Story

Thank you for helping out with Treeherder!

You can find us on IRC at irc://irc.mozilla.org/treeherder

Here's some links to help get you started.

Project page:
https://wiki.mozilla.org/Auto-tools/Projects/Treeherder

Repo locations and links to set up a development version of the software:
https://wiki.mozilla.org/Auto-tools/Projects/Treeherder#Getting_Started

Interacting with us:
https://wiki.mozilla.org/Auto-tools/Projects/Treeherder#Contributing

A-Team general reference, coding style guides:
http://ateam-bootcamp.readthedocs.org
After using treeherder a bit more I've realised why I get so confused when looking at some of the jobs - it's taking me a while to understand/skim read the job attributes.

After selecting a job, the job details panel shows something like:

Machine name: talos-linux64-ix-073
Build: x86_64 linux64 linux
Buildbot job name: Ubuntu HW 12.04 x64 mozilla-central talos chromez
Duration: 13 minute(s)
Job name: Talos chrome
Machine : x86_64 linux
Start time: 8/28/14 10:21 PM 

Some of these attribute names could be tweaked to be slightly clearer.

eg:
Job name -> Job type
Build -> Platform
Machine name -> Machine

We can delete "Machine" due to bug 1056928 and re-add it in the future if we fix it.

We should also tweak the order, so that more important things like "Job name" and "Platform" are nearer the top - which speeds up the time to recognise the current job type when sheriffing (important since when pressing the j/k keys you end up on arbitrary jobs without having seen the job symbol as you would when clicking on a job directly).
I also think we should swap the ordering of some of the concatenated fields & remove the redundancy, eg:

Build (aka platform): 
"x86_64 linux64 linux" -> "linux64"
"x86 android-4-2-x86 android" -> "android-4-2-x86"
"x86 windowsxp win" -> "windowsxp"

But perhaps that's best done in another bug (since need to decide which attributes to use & if we want a friendly description for them etc).
Summary: Job details: Tweak the labels for various job attributes (eg "Job name") → Job details: Tweak job attribute labels & ordering
Assignee: emorley → nobody
Status: ASSIGNED → NEW
Priority: P2 → P3
No longer blocks: treeherder-dev-transition
Keywords: regression
Priority: P3 → P4
Putting this up as a good first bug. Yeah, we probably want broad consensus from sheriffs and other key users evaluating this reordering on dev, before it gets propagated to stage/prod.

I think we just want to be mindful of muscle-memory/visual-memory type changes like this.
Mentor: emorley
User Story: (updated)
Whiteboard: [good first bug]
Whiteboard: [good first bug] → [good first bug][lang=js]
i want to take this bug :)
Assignee: nobody → tapesh.mandal
Status: NEW → ASSIGNED
Hi,
   please suggest new replacement for names and preffered change in the order ..kindly let me know your choices by commenting here :-)
Flags: needinfo?(tojonmz)
Flags: needinfo?(ryanvm)
Flags: needinfo?(philringnalda)
Flags: needinfo?(emorley)
Flags: needinfo?(cbook)
Presently we have something like:

Job: Ubuntu VM 12.04 mozilla-central opt test cppunit (*link)
Machine name: tst-linux32-spot-183 (*link)
Build: x86 linux32 linux (*link)
Job name: CPP Unit Tests
Requested: Wed Apr 15, 13:35:02
Started: Wed Apr 15, 13:35:26
Ended: Wed Apr 15, 13:46:46
Duration: 11 minute(s)
Log parsing status: parsed 

I think it's reasonable that the 3 linked items at the top remain grouped together. Perhaps we could adjust "Machine name:" to "Machine:" (nice declutter) and perhaps "Job name:" to "Job type:" if Sheriffs feel that is more intuitive. I am not sure what re-ordering if any still needs to take place, and defer to Sheriffs on that. We just need to be mindful we have lots of users, so changing order needs to be compellingly better imo :)
Flags: needinfo?(tojonmz)
The only thing I would be actually interested in seeing move would be getting the TinderboxPrint'ed pass/fail/todo count out of somewhere-random-at-the-bottom up to the top where it should be as the single most important thing in that panel. Beyond that, for things which are actually in scope for this bug, doesn't matter to me, though it might be wise not to do too much in there until TaskCluster settles in to deciding what it will actually provide you, since it's currently giving a combination of bad data and no data for the things this bug is about.
Flags: needinfo?(philringnalda)
script_revlink should definitely be lower down. I'd like to see the job pass/fail count higher. Also, I'd love the screenshot link to be easier to find when there is one. Not sure how doable that would be, though.
Flags: needinfo?(ryanvm)
Respected Sir,
              i did not get the pass/fail attribute...are you talking about the Result tag..it is already at the top ..if not kindly tell me the name (like Machine name) of the attribute which you want to be higher in the list.. :-)

Thanking you for the response to the earlier comment..your opinion is valuable :-)

Regards
 
Tapesh Mandal
Flags: needinfo?(ryanvm)
Flags: needinfo?(philringnalda)
Let me try again, since we're just confusing you talking about other things which appear in that same panel, down below the labelled things that this bug is about.

No working sheriffs have any opinion about the order of the labelled things, or about what the labels are - that just doesn't matter to us at all. Ed filed the bug, he apparently felt they should be shuffled around and relabelled, so he's the one with an opinion about them. We're all fine with the current order, and the current labels, or with a different order and different labels.
Flags: needinfo?(ryanvm)
Flags: needinfo?(philringnalda)
Flags: needinfo?(cbook)
Hi 
  Ed the ball is in your court now :P ..everyone has given their valuable opinion about the changes..(kindly refer to the above made comments)..Sir please help me finalize the changes..so that i can make the required modifications and push changes to the repo..

Eagerly waiting for your reply. i would be happier you list the changes for me ..dont worry we could have a discussion about adding or deleting any changes as required :D

Best
Tapesh Mandal
Hi 
  Ed the ball is in your court now :P ..everyone has given their valuable opinion about the changes..(kindly refer to the above made comments)..Sir please help me finalize the changes..so that i can make the required modifications and push changes to the repo..

Eagerly waiting for your reply. i would be happier you list the changes for me ..dont worry we could have a discussion about adding or deleting any changes as required :D

Best
Tapesh Mandal
The list of labels has been changed several times since this bug was filed, so it's slightly better, but still suboptimal. eg: I believe bug 1056928 is still an issue.

Anyway if other people aren't fussed, I'm not either - and regardless I don't think this is a good first bug, since it needs someone who is used to the workflow to have a play about.

Tapesh, perhaps have a look at bugahoy and see if there is something else there that takes your interest? :-)
Assignee: tapesh.mandal → nobody
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(emorley)
Resolution: --- → INCOMPLETE
Whiteboard: [good first bug][lang=js]
(In reply to Phil Ringnalda (:philor) from comment #7)
> The only thing I would be actually interested in seeing move would be
> getting the TinderboxPrint'ed pass/fail/todo count out of
> somewhere-random-at-the-bottom up to the top where it should be as the
> single most important thing in that panel.

Is this to check things haven't been accidentally disabled? If so, that use case is covered by the tool that ahal wrote (and ideally should be built into treeherder somewhere explicitly. I don't think solving the use case this way is ideal - I'd like to fix the root cause if possible :-)

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #8)
> script_revlink should definitely be lower down. I'd like to see the job
> pass/fail count higher. Also, I'd love the screenshot link to be easier to
> find when there is one. Not sure how doable that would be, though.

script_revlink is just one of the tinderboxprints - which are I believe just displayed in the order they are in the log. We could try and hardcode some to be displayed first, but that seems a bit hacky. Re the screenshot, we have a bug filed to add it to the log viewer I think? Happy for you to file bugs for these if you want :-)
Not for looking at the actual total number, no, for sometimes seeing the number of failures ("wups, I'm blaming 500 failures on that bug, when it should only be 6") but mostly for seeing the difference between 9999/1/7 CRASH in a suite that survives crashes and T-FAIL CRASH in a suite that has to be retriggered on crashes, and for seeing 9999/1/7 876/1/3 999/1/9 in Moth to realize there are plugins and a11y failures down below the top chrome failure.
Ah thank you for that list. IMO those are all things we should surface elsewhere (eg error summary) - could you file some bugs? :-)
You need to log in before you can comment on or make changes to this bug.