Re: Treeherder New Login Flow
On 2/9/18 9:30 AM, ha...@mozilla.com wrote: > - Treeherder session will stay alive as long as access to the site > happens once every 24 hours. 3 days session expiry is no longer in > effect. This doesn't seem to be the case: I'm logged in when I go to bed, and 7 hours later when I get up I'm logged out; I'm logged in when I leave for work, and 4.5 hours later when I get home on my lunch hour I'm logged out. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Feedback requested: UI changes for Treeherder
On 10/10/16 11:57 AM, Jonathan Griffin wrote: > We may implement these wireframes for non-sheriffs, or on a per-user basis, > or only for Try. Thinking in terms of "developers look at single pushes on try, sheriffs look at multiple pushes on non-try" is wrong on all four counts. Many of the developer bugs filed on treeherder are because they keep open an "&author=" tab showing several of their try pushes at once; I push to try quite a bit, as do other sheriffs; I also sometimes look at single pushes on other trees (generally for the same thing a developer, or I, am looking for while looking at a try push: is everything on this particular push done and good, so I can send this push to its next destination?); any developer who never looks at the results of their pushes anywhere other than try is just throwing themselves completely on the mercy of sheriffs, not a group widely known for mercy. Instead what we should be doing is developing a great single-push view, which might include some (though certainly not all, widely separating failures from passes of the same job is horrifying) of the features in those mockups. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Some data on mozilla-inbound
On 4/22/13 12:54 PM, Kartikaya Gupta wrote: > I looked at all the build.json files [4] from the 6th of April to the > 17th of April and pulled out all the jobs that corresponding to the > "push" changesets in my range above. For this set of 553 changesets, > there were 500 (exactly!) distinct "builders". 111 of these had "-pgo" > or "_pgo" in the name, and I excluded them. I created a 553x389 matrix > with the remaining builders and filled in how much time was spent on > each changeset for each builder (in case of multiple jobs, I added the > times). > > Then I assumed that any empty field in the 553x389 matrix was a result > of coalescing. This is a grossly simplifying assumption that I would > like to revisit - I know for Android changes we can detect that in some > cases and only run the relevant tests; my assumption means the rest of > the platforms are considered "coalesced" for these changes. I filled in > these fields in the matrix with the average time spent on all the other > builds for that builder in the matrix. > > * A total of 228717299 seconds were spent on the 128777 entries in the > matrix > * After de-coalescing, a total of 373751505 seconds would have been > spent on the 215117 entries in the matrix (an increase of 63%) > * With coalescing, but removing all the backout pushes and pushes that > were completely backed out, a total of 173027517 seconds were spent on > 97623 entries (down 24% from actual usage) > * With de-coalescing AND stripping backouts, a total of 292634211 > seconds would have been spent on the 168437 entries (an increase of 27% > over actual usage) Too many iffy things to say that those percentages are anything other than numbers between 1 and 100, I'm afraid. Not only do Android-only pushes only build Android, b2g-only pushes only build b2g, and browser/-only pushes only build desktop, and jobs with spidermonkey in the name are only built for pushes that touch js/src/. You can tell the difference between coalescing and intentionally only building one product by looking at self-serve, where a push that only intended to build Android will only list the Android builds, while a push that intended to build everything but had everything but Android coalesced away will still show all the other builds, even though they actually ran on a different push, so I presume there's a way to query buildapi to find out whether a missing build was coalesced or just not triggered at all. Your range, April 6 - April 17, includes two full weekends (when coalescing barely exists) but only a week and a half of weekdays, when coalescing actually happens. It also includes the travel weekend before, and a half week of a b2g workweek when b2g patches were first not landing at all, and then landing on birch instead of inbound, dropping coalescing, but because birch granted itself the second-highest possible priority, coalescing could also have be more extreme on inbound while birch was starving it of slaves. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Some data on mozilla-inbound
On 4/24/13 9:50 PM, Ehsan Akhgari wrote: > No. But that's not what I was talking about. Whether something lands > directly on try is a judgement call, and some people may be better at it > than others. As someone who has stopped using try server as a rule > (because of the excessive wait times there, which I find unacceptable > for day-to-day work), I always ask myself what are the chances that this > thing that I want to push could bounce, and I test on try only when I > can convince myself that the chances are slow. All I was suggesting was > give people a way to assess whether they're good at making these calls, > and improve it if they're not. I'm curious about what you think the wait times are, and what wait times you would find acceptable. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load
On 4/25/13 1:12 PM, Ed Morley wrote: > On 25 April 2013 20:14:10, Justin Lebar wrote: >>> Is this what you're saying? >>> * 10.6 opt tests - per-checkin (no change) >>> * 10.6 debug tests- reduced >>> * 10.7 opt tests - reduced >>> * 10.7 debug tests - reduced >>> >>> * reduced --> m-c, m-a, m-b, m-r, esr17 >> >> Yes. >> >> Now that I think about this more, maybe we should go big or go home: >> change 10.6 opt tests to reduced as well, and see how it goes. We can >> always change it back. >> >> If it goes well, we can try to do the same thing with the Windows tests. >> >> We should get the sheriffs to sign off. > > Worth a shot, we can always revert :-) Only thing I might add, is that > we'll need a way to opt into 10.6 test jobs on Try, in case someone has > to debug issues found on mozilla-central (eg using sfink's undocumented > OS version specific syntax). So what we're saying is that we are going to completely reverse our previous tree management policy? Currently, m-c is supposed to be the tree that's safely unbroken, and we know it's unbroken because the tests that we run on it have already been run on the tree that merged into it, and you should almost never push directly to it unless you're in a desperate hurry to hit a nightly. This change would mean that we expect to have merges of hundreds of csets from inbound sometimes break m-c with no idea which one broke it, that we expect to sometimes have permaorange on it for days, and that it's better to push your widget/cocoa/ pushes directly to m-c than to inbound. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Some data on mozilla-inbound
On 4/25/13 4:47 PM, Wesley Johnston wrote: > Requesting one set of tests on one platform is a 6-10 hour turnaround for me. That's surprising. https://tbpl.mozilla.org/?tree=Try&rev=9d1daf69061d was a midday -b do -p all -u all with a 3 hour 40 minute end-to-end. Or did you mean, as a great many people do while discussing try these days, "back in February when I stopped using try because it was so awful then, requesting one set of tests..."? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Some data on mozilla-inbound
On 4/26/13 8:25 AM, Wesley Johnston wrote: > Maybe. I started to avoid it if possible around then, but almost 4 hours for > results still is basically unusable. Tell me about it - that's actually the same as the end-to-end on inbound/central. Unfortunately, engineering is totally indifferent to things like having doubled the cycle time for Win debug browser-chrome since last November. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load
On 4/26/13 8:11 AM, Justin Lebar wrote: >> So what we're saying is that we are going to completely reverse our >> previous tree management policy? > > Basically, yes. > > Although, due to coalescing, do you always have a full run of tests on > the tip of m-i before merging to m-c? It's not just coincidence that the tip of most m-i -> m-c merges is a backout - for finding a mergeable cset in the daytime, you're usually looking at the last backout during a tree closure, when we sat and waited to get tests run on it. Otherwise, you pick one that looks possible, and then figure out what got coalesced up and see how that did where it got coalesced. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is there any reason not to shut down bonsai?
On 11/21/13, 11:43 AM, Laura Thomson wrote: > If you don't know what that is--and few people do, which is even more > reason to shut it off--it's a search engine for some of our CVS > repositories, of which I think none are in active development. Thanks for the reminder that it still exists - I just used it to successfully figure out what to do in the heat of tree-bustage-battle (and no, I wouldn't have liked to install git, clone an enormous git repo, and look up some complicated git command to do approximately the same thing instead). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The state of the Aurora branch
On 1/18/13 2:06 PM, Mihai Sucan wrote: > At this point I hope aurora reopens ASAP. Apologies for the trouble. Nope. The devtools leaks, while interesting and potentially troublesome, weren't really a significant tree-closing problem. Now we're down to Linux64 and Win7 both failing (by which I mean the test suite does not complete, so we have no way of knowing when people introduce new failures) in ways that look exactly like the June/July and October 2012 episodes where we started out by disabling webtools tests, until we had disabled them all and we still OOMed in other tests. Are our users also having OOM troubles on 20, or on 20 and on 21 if they have testpilot installed? Dunno. Have we introduced bustage since 20 merged to Aurora which affects either or both of Linux64 or Win7 when testpilot is installed, bustage which is caught by browser-chrome tests, but those tests do not run because the suite dies before it gets to them, bustage which affects users? We *cannot* know. The thing that we ship to Aurora users? We don't know whether it's any good or not, we only know that the thing which we do not ship to them is good. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
