Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

TBPL changes pushed today & reminder about keyboard shortcuts

121 views
Skip to first unread message

Ed Morley

unread,
Jun 8, 2012, 11:07:47 AM6/8/12
to
Over the last couple of weeks I've been getting familiar with the TBPL codebase with the aim of smoothing out some of TBPL's rougher edges. (Seeing how much of my day I spend interacting with it!).

The first round of changes rolled out today (bug 760321), the most significant being:
* &usetinderbox=1 support has now been removed \o/
* The failure squares displayed top right of the UI that broke the layout when there were more than X failures have been removed. They served little purpose other than for navigating from one unstarred failure to the next, which has been possible using keyboard shortcuts for some time.
* The concept of latest job of each type has been removed (possible now that the failure squares don't exist), allowing for a fair bit of simplification. This also means that unstarred failures can no longer be obscured by later greens, meaning the number displayed in the tab title/top right of the UI is actually accurate (/more meaningful in a 'everything-should-be-starred' world).

*Ok, so how does this affect me?*

If you used to use the failure run squares to navigate between unstarred jobs, you will now want to use the 'j' and 'k' keys to navigate between them. You can also enable unstarred-only view (press 'u' or tick the 'Only unstarred checkbox in the filters menu) to make things even clearer.

For a list of these keyboard shortcuts (and more), look under the 'help' menu top left of the UI.

I have a list of a few ideas for TBPL that I'll be working on over the coming weeks, but if there is something specific people would like to see, please do file a bug :-)
https://bugzilla.mozilla.org/enter_bug.cgi?product=Webtools&component=Tinderboxpushlog

Cheers,

Ed

Armen Zambrano G.

unread,
Jun 8, 2012, 11:58:48 AM6/8/12
to
+1 Thanks Ed!

L. David Baron

unread,
Jun 10, 2012, 4:29:12 PM6/10/12
to Ed Morley, dev-pl...@lists.mozilla.org
On Friday 2012-06-08 08:07 -0700, Ed Morley wrote:
> * The concept of latest job of each type has been removed
> (possible now that the failure squares don't exist), allowing for
> a fair bit of simplification. This also means that unstarred
> failures can no longer be obscured by later greens, meaning the
> number displayed in the tab title/top right of the UI is actually
> accurate (/more meaningful in a 'everything-should-be-starred'
> world).

I fundamentally disagree with this change; it makes tbpl display
less useful state about whether the tree is currently healthy in
favor of using it as an enforcement mechanism for starring of
intermittent (or non-intermittent) test failures. While having
knowledge of our intermittent test failures is an important aspect
of keeping the tree healthy in the long run, I don't think it's
important enough that we should stop displaying information about
the current health of the tree in order to force people to annotate
old intermittent failures.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

Ed Morley

unread,
Jun 11, 2012, 6:33:31 AM6/11/12
to
On Sunday, June 10, 2012 9:29:12 PM UTC+1, L. David Baron wrote:
> I fundamentally disagree with this change; it makes tbpl display
> less useful state about whether the tree is currently healthy in
> favor of using it as an enforcement mechanism for starring of
> intermittent (or non-intermittent) test failures. While having
> knowledge of our intermittent test failures is an important aspect
> of keeping the tree healthy in the long run, I don't think it's
> important enough that we should stop displaying information about
> the current health of the tree in order to force people to annotate
> old intermittent failures.

Hi David

This was most definitely not done to force people to annotate old intermittent failures. There are only ~6 people who've regularly filed intermittent oranges over the last 3 months and I do not believe for a second this would change that.

What it does do however, is make my & any other sheriffs' lives a lot less repetitive when it comes to monitoring the trees - since prior to this change, I/we would have to routinely cycle through the ~10 TBPL tabs we had open, since the tab title could say "[0] Mozilla-Inbound" but be lying and there in fact still be unstarred failures that needing dealing with. After the change, I can actually trust the tab title, which I hope will save me in the order of 20-25 mins each and every day (very rough sums, but it's in that ballpark).

In addition, the failure squares/count was not actually an accurate indicator for the health of the tree:
* The "last job of each type" concept was broken, such that if a previous push's job finished after a newer one, then that result would be used instead, falsely telling you that the tip was green, when in fact it may not be.
* Now that PGO is not done per push (and given that the pgo-only failure rate has sadly been higher than predicted when the idea was proposed), having a green tip is still not an indicator of a healthy tree, or that it is ready to be merged, since we have to specifically look for a push that had PGO to merge from that.
* Same as above, but with coalescing of jobs. The 'tree heath' boxes may not be showing orange/red, but 75% of the tests haven't been run for 10 pushes (or there's just loads of pending), so the tree could actually be utterly busted.

Given that it wasn't accurate and yet people were treating it as such (as proven by your post), it hindered monitoring multiple TBPL tabs & completely busted the layout whenever there were over X failures, I believe removing it was the right thing to do. However, I agree that a useful addition to TBPL would be a "can push/don't push" light (with an algorithm that tries to at least take into account some of the points above), a la bug 568819.

If you have any further questions, please let me know :-)

Best wishes,

Ed
0 new messages