On 16 February 2016 at 16:38, Nick Fitzgerald wrote:
> It seems like try/tbpl could automatically detect new test files and run
> them N times. That way, the developer doesn't have to do it manually, so it
> is less "intimidating" and also less likely to be skipped by accident or
> forgotten.
We
I've heard of other companies putting new tests into "quarantine" like
this, it's a reasonable idea.
I think the suggestion of running new tests under rr chaos mode is to
explicitly find timing bugs of the type that chaos mode exposes, which
tend to be hard to reproduce otherwise (but manifest as
It seems like try/tbpl could automatically detect new test files and run
them N times. That way, the developer doesn't have to do it manually, so it
is less "intimidating" and also less likely to be skipped by accident or
forgotten.
Running under rr would be nice, but even without rr this seems li
On 16/02/16 03:15, Kyle Huey wrote:
Seems like a good thing to expect developers to do locally today.
Two concerns:
What's the successs criteria here?
Also, speaking as an occasional code contributor, newcomers and folks
like me will probably give up on contributing patches earlier.
Axel
On Mon, Feb 15, 2016 at 6:26 PM, Kyle Huey wrote:
> rr runs fine under VMWare ;)
>
Yes, but asking developers to fire up a VM and sync their changes to that
VM when adding a test adds a pretty high impediment to adding a test. (Your
post might have tongue-in-cheek on this point, but I can't quit
On Mon, Feb 15, 2016 at 6:15 PM, Kyle Huey wrote:
> Seems like a good thing to expect developers to do locally today.
>
I don't think that's realistic for developers who aren't on Linux.
>
> - Kyle
>
> On Mon, Feb 15, 2016 at 6:08 PM, Justin Dolske wrote:
>
> > On 2/14/16 9:25 PM, Bobby Holle
rr runs fine under VMWare ;)
- Kyle
On Mon, Feb 15, 2016 at 6:18 PM, Bobby Holley wrote:
> On Mon, Feb 15, 2016 at 6:15 PM, Kyle Huey wrote:
>
>> Seems like a good thing to expect developers to do locally today.
>>
>
> I don't think that's realistic for developers who aren't on Linux.
>
>
>>
>
Seems like a good thing to expect developers to do locally today.
- Kyle
On Mon, Feb 15, 2016 at 6:08 PM, Justin Dolske wrote:
> On 2/14/16 9:25 PM, Bobby Holley wrote:
>
> How far are we from being able to use cloud (rather than local) machine
>> time to produce a trace of an intermittently-fa
On 2/14/16 9:25 PM, Bobby Holley wrote:
How far are we from being able to use cloud (rather than local) machine
time to produce a trace of an intermittently-failing bug? Some one-click
procedure to produce a trace from a failure on treeherder seems like it
would lower the activation energy signi
On 2/14/16 9:16 PM, Robert O'Callahan wrote:
Lots of tests have been disabled for intermittency over the years. Now we
have the ability to fix (at least some of) them without much pain, it may
be worth revisiting them, though i don't know how to prioritize that.
We might want to revisit our work
On Mon, Feb 15, 2016 at 10:58 PM, Gijs Kruitbosch
wrote:
> On 15/02/2016 05:16, Robert O'Callahan wrote:
>
>> At this point the limiting factor is getting developers to actually debug
>> and fix recorded test failures.
>>
>
> Well, and platform (OS) support for rr, right? And rr also doesn't
> ef
On 15/02/2016 05:16, Robert O'Callahan wrote:
At this point the limiting factor is getting developers to actually debug
and fix recorded test failures.
Well, and platform (OS) support for rr, right? And rr also doesn't
effectively support debugging frontend JS tests, AIUI? Have either of
thos
On Mon, Feb 15, 2016 at 7:21 PM, Mike Hommey wrote:
> Relatedly, roc, is it possible to replay, on a different host, with
> possibly a different CPU, a record that would have been taken on the
> cloud? Does using a VM make it possible? If yes, having "the cloud" (or
> a set of developers) try to
On Mon, Feb 15, 2016 at 6:26 PM, Kyle Huey wrote:
>
> FWIW, every failure that I've debugged to completion so far has been a bug
> in the test (although I have two fatal assertion bugs I'm working through
> that will obviously be flaws in Gecko). I think one of the things we
> really want to get
I've got RR working under digital oceans and it works great there.
We've built a harness for generating replays. Once a replay is generated I
match the replay with the bug and comment in the bug looking for developers
to investigate. When they respond they can investigate by ssh'ing. Example:
http
On Sun, Feb 14, 2016 at 09:25:58PM -0800, Bobby Holley wrote:
> This is so. Damn. Exciting. Thank you roc for having the vision and
> persistence to bring this dream to reality.
>
> How far are we from being able to use cloud (rather than local) machine
> time to produce a trace of an intermittent
On Sun, Feb 14, 2016 at 9:37 PM, L. David Baron wrote:
> On Sunday 2016-02-14 21:26 -0800, Kyle Huey wrote:
> > On Sun, Feb 14, 2016 at 9:16 PM, Robert O'Callahan
> wrote:
> > > Over the last few days we have had a lot of positive experiences
> > > reproducing bugs with rr chaos mode. Kyle tells
On Sunday 2016-02-14 21:26 -0800, Kyle Huey wrote:
> On Sun, Feb 14, 2016 at 9:16 PM, Robert O'Callahan
> wrote:
> > Over the last few days we have had a lot of positive experiences
> > reproducing bugs with rr chaos mode. Kyle tells me that, in fact, he's been
> > able to reproduce every single
This is so. Damn. Exciting. Thank you roc for having the vision and
persistence to bring this dream to reality.
How far are we from being able to use cloud (rather than local) machine
time to produce a trace of an intermittently-failing bug? Some one-click
procedure to produce a trace from a failu
On Sun, Feb 14, 2016 at 9:16 PM, Robert O'Callahan
wrote:
> Over the last few days we have had a lot of positive experiences
> reproducing bugs with rr chaos mode. Kyle tells me that, in fact, he's been
> able to reproduce every single bug he tried with enough machine time thrown
> at it.
>
Of f
20 matches
Mail list logo
