On 2016-04-26 05:54 PM, Mike Hommey wrote:
On Tue, Apr 26, 2016 at 03:49:11PM +0200, Gabor Krizsanits wrote:
As someone who was high on the list of try server usage for two
weeks My problem was a test I tried to fix for both e10s and
non-e10s, and it timed out _sometimes_ on _some_ platform
Running that mach try command with the additional --no-push argument
produces this mouthful:
try: -b do -p linux64 -u
crashtest,crashtest-e10s,mochitest-1,mochitest-browser-chrome-1,mochitest-e10s-1,mochitest-e10s-browser-chrome-1,mochitest-o,reftest,reftest-e10s,xpcshell
-t none --try-test-paths
On Tue, Apr 26, 2016 at 03:49:11PM +0200, Gabor Krizsanits wrote:
> As someone who was high on the list of try server usage for two
> weeks My problem was a test I tried to fix for both e10s and
> non-e10s, and it timed out _sometimes_ on _some_ platforms even
> depending on debug/release buil
On 26/04/2016 14:01, James Graham wrote:
Based on a conversation yesterday, it seems that the features of |mach
try| are not well known. In particular it allows running only a subset
of tests in cases that you are doing an experimental push that you
expect to affect mainly one area of the code. F
As someone who was high on the list of try server usage for two weeks
My problem was a test I tried to fix for both e10s and non-e10s, and it
timed out _sometimes_ on _some_ platforms even depending on debug/release
build. It was a whack-a-mole game by fiddling with the test and a complex
patch
On 15/04/16 16:47, Ryan VanderMeulen wrote:
I'm sure most of you have experienced the pain of long backlogs on Try
(Windows in particular). While we'd all love to have larger pools of test
machines (and our Ops people are actively working on improving that!), one
often-overlooked thing people can
Ryan VanderMeulen
writes:
> Treeherder makes it easy to do this - just hit the little circle with an X
> icon on the right hand side adjacent to the "XX% - Y in progress" text
> along the top bar of the push. You will be prompted whether you really want
> to cancel all jobs on the push. Just hit
Any conclusions out of the discussion here? Try is getting slower as we
speak...
I would opt to less disruptive way at first, per what Brian Grinstead said.
We don't even have to implement interactive prompt first. If that makes
people cancel old Try runs more, great, if not, we could consider oth
On 2016-04-18 2:46 PM, William Lachance wrote:
Treeherder did trigger a rather large memory leak which got fixed in the
browser a while back (Dec 2015), so please consider revisiting it if you
gave up around then:
...
If anyone feels like profiling and submitting patches, we'd welcome the
help.
On 2016-04-16 5:50 AM, Gijs Kruitbosch wrote:
On 16/04/2016 01:24, Steve Fink wrote:
Doesn't everyone keep a tab open to their try page? eg I have
https://treeherder.mozilla.org/#/jobs?repo=try&author=sf...@mozilla.com
open all the time.
No. Treeherder is too resource-intensive to keep open fo
Default should probably be fail push rather than auto cancel.. But +1 to
opting into parallel push explicitly. I've certainly used that on a few
occasions.
But the PSA here may be the most important part..
On Apr 15, 2016 3:37 PM, "Jonas Sicking" wrote:
We could also make the default behavior be
On 17/04/2016 22:54, Mike Conley wrote:
Generally speaking, Firefox's stability has not been good for me for 2-3
months. I'd like to file a bug, > but I've already used up my quota of
unactionable bugs, and if I dug into all of my idiosyncratic
issues I'd never get any work done. I seem to do t
On Apr 17, 2016 1:55 PM, "Steve Fink" wrote:
>
> Generally speaking, Firefox's stability has not been good for me for 2-3
months. I'd like to file a bug, but I've already used up my quota of
unactionable bugs, and if I dug into all of my idiosyncratic issues I'd
never get any work done.
Also (and
> Generally speaking, Firefox's stability has not been good for me for 2-3
months. I'd like to file a bug, > but I've already used up my quota of
unactionable bugs, and if I dug into all of my idiosyncratic
> issues I'd never get any work done. I seem to do things differently, in
some problematic w
If I had to guess, I'd say that it's just consuming more and more memory as
more and more nodes are getting added to the DOM, and more AngularJS stuff
gets instantiated.
I would put good money on those multi-second pauses being attempts to GC /
CC
On 16 April 2016 at 05:50, Gijs Kruitbosch wrot
That's a very good point about keeping the treeherder page open eating
resources. I guess I've found that (1) my personal try push page takes
much, much longer to get overloaded than eg the inbound page (or worse,
the *full* try page); and (2) Firefox is so flaky on me for other
reasons that I
On Sun, Apr 17, 2016 at 3:11 AM, L. David Baron wrote:
>
> We should instead use data to target advice on use of try to the
> correct people, and also use that data to allow people to see where
> they fit in in terms of ratios of Try resource usage to pushes, and
> breaking the tree to pushes.
We
On Saturday 2016-04-16 10:50 +0100, Gijs Kruitbosch wrote:
> On 16/04/2016 01:24, Steve Fink wrote:
> >Doesn't everyone keep a tab open to their try page? eg I have
> >https://treeherder.mozilla.org/#/jobs?repo=try&author=sf...@mozilla.com
> >open all the time.
>
> No. Treeherder is too resource-i
On 16/04/2016 01:24, Steve Fink wrote:
Doesn't everyone keep a tab open to their try page? eg I have
https://treeherder.mozilla.org/#/jobs?repo=try&author=sf...@mozilla.com
open all the time.
No. Treeherder is too resource-intensive to keep open for long periods
of time. I tend to see multi-se
On Friday, April 15, 2016 at 5:11:55 PM UTC-7, Xidorn Quan wrote:
> On Sat, Apr 16, 2016 at 1:47 AM, Ryan VanderMeulen <
> rvandermeu...@mozilla.com> wrote:
>
> > I'm sure most of you have experienced the pain of long backlogs on Try
> > (Windows in particular). While we'd all love to have larger
On Sat, Apr 16, 2016 at 10:24 AM, Steve Fink wrote:
> On 04/15/2016 05:11 PM, Xidorn Quan wrote:
>
>> On Sat, Apr 16, 2016 at 1:47 AM, Ryan VanderMeulen <
>> rvandermeu...@mozilla.com> wrote:
>>
>> I'm sure most of you have experienced the pain of long backlogs on Try
>>> (Windows in particular).
On 04/15/2016 05:11 PM, Xidorn Quan wrote:
On Sat, Apr 16, 2016 at 1:47 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:
I'm sure most of you have experienced the pain of long backlogs on Try
(Windows in particular). While we'd all love to have larger pools of test
machines (and our Op
On Sat, Apr 16, 2016 at 1:47 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:
> I'm sure most of you have experienced the pain of long backlogs on Try
> (Windows in particular). While we'd all love to have larger pools of test
> machines (and our Ops people are actively working on improvi
> On Apr 15, 2016, at 12:44 PM, Jim Blandy wrote:
>
> On Fri, Apr 15, 2016 at 12:36 PM, Jonas Sicking wrote:
>
>> We could also make the default behavior be to cancel old pushes. And
>> then enable push message syntax for opting in to not cancelling.
>>
>>
> This could be very frustrating (a
I also often have multiple pushes going at the same time. My
suggestion to solve this problem is: have a cron job that detects
users who have more than N pushes with jobs still going, and send them
an email saying "you have a lot of jobs going, here's the list; you
might find something you should c
On 4/15/16 1:09 PM, Tim Guan-tin Chien wrote:
I wonder if there is any use cases to do multiple Try pushes of different
changesets but with the same bug number.
A significant fraction of my try pushes are like this, actually.
Typically this happens when I do a try push of a multi-changeset que
On 15/04/2016 20:46, Mike Connor wrote:
For cases where a developer needs to run multiple runs at once, we can add
an override in the trychooser syntax. I think that's a corner case
It isn't when you do any kind of talos "need to fix / not regress perf"
work.
I agree with Jim that we should
See bug 593096. (Hah! I anticipated you guys by almost 700,000 bugs!)
It's currently WONTFIX, but there's some relevant discussion in there.
On 04/15/2016 12:46 PM, Mike Connor wrote:
If this is a serious problem, and I can easily believe that it is, have we
considered having a default behaviou
If this is a serious problem, and I can easily believe that it is, have we
considered having a default behaviour of cancelling all unfinished Try jobs
running for a given user when they push again? Based on how I've seen
people use Try over the years, I suspect a significant majority of pushes
are
On Fri, Apr 15, 2016 at 12:36 PM, Jonas Sicking wrote:
> We could also make the default behavior be to cancel old pushes. And
> then enable push message syntax for opting in to not cancelling.
>
>
This could be very frustrating (and cause farm work to be wasted) if it
happened accidentally.
Perh
We could also make the default behavior be to cancel old pushes. And
then enable push message syntax for opting in to not cancelling.
/ Jonas
On Fri, Apr 15, 2016 at 10:19 AM, James Graham wrote:
> On 15/04/16 18:09, Tim Guan-tin Chien wrote:
>>
>> I wonder if there is any use cases to do multip
On 15/04/16 18:09, Tim Guan-tin Chien wrote:
I wonder if there is any use cases to do multiple Try pushes of different
changesets but with the same bug number. Should we automatically cancel the
old ones when there is a new one?
Unfortunately there are legitimate uses for e.g. comparing the eff
I wonder if there is any use cases to do multiple Try pushes of different
changesets but with the same bug number. Should we automatically cancel the
old ones when there is a new one?
On Fri, Apr 15, 2016 at 8:47 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:
> I'm sure most of you hav
33 matches
Mail list logo
