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 "=" 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: 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: 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/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: 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: 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
