Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

On Wed, Aug 10, 2016 at 6:47 AM, Lars Bergstrom wrote: > But in this model, there's also "is this a failure from one of the N > PRs before me?" which isn't a type of failure that is common (AFAIK) > when contributing to OSS projects. Intermittents, especially when they >

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

On Mon, Aug 8, 2016 at 11:16 AM, Olaf Buddenhagen wrote: > >> This seems to trade time for machines by optimistically assuming all >> previous PRs passed tests. > > Right. > > As long as intermittent failures are rare, I think it's a fair > assumption. (Actual bugs

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

If an intermittent failure happens in an auto-rollup job, it'll just split it and run all the tests again on the halves. Assuming the intermittent is rare, both those halves will probably pass and it'll land. It has log[2]N tries before it gives up. If the intermittent is common, we want to do

Re: [dev-servo] Questions about constellation, sandboxing and multiprocess

Hi, On Thu, Aug 04, 2016 at 02:25:26PM +0100, James Graham wrote: > On 04/08/16 12:24, Olaf Buddenhagen wrote: > > On Wed, Aug 03, 2016 at 06:22:51PM +0200, Till Schneidereit wrote: > > > I'm not concerned about code complexity, but about memory usage. Memory > > > usage in many-tab scenarios is

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

Hi, On Thu, Aug 04, 2016 at 12:45:50PM -0700, Bobby Holley wrote: > One fundamental problem with precommit testing the precise commit to be > merged is that intermittents are more costly. You either have to hold up > the pipeline while you retrigger the intermittent job, or throw away all of >

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

Hi, On Fri, Aug 05, 2016 at 11:03:27AM +0530, Manish Goregaokar wrote: > At the time, Firefox's model wouldn't fit well because semantic > conflicts during merge are an issue -- not actual git merge conflicts, > but two changes which are compatible with their respective parents > but not with

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

Hi, On Thu, Aug 04, 2016 at 04:58:06PM +, Michael Howell wrote: > Actually (though I've been busy implementing other things), I've been > planning a somewhat different way to solve the scalability problems that I > called "auto rollup." [...] In the absence of intermittent failures, this

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

Hi, On Thu, Aug 04, 2016 at 12:45:24PM -0600, Jack Moffitt wrote: > > Actually (though I've been busy implementing other things), I've been > > planning a somewhat different way to solve the scalability problems that I > > called "auto rollup." [...] > It does share one of the same drawbacks as

Re: [dev-servo] Feature detector detector for Servo debugging

It triggers for all, but the python script filters for accesses to properties that actually should be there. I wanted it to be easy to change the filtering logic without recompiling everything. -Manish Goregaokar ___ dev-servo mailing list

Re: [dev-servo] Feature detector detector for Servo debugging

Does the feature detector detector trigger on undefined accesses to *all* JavaScript objects, or just host objects? On Tue, Aug 9, 2016 at 4:42 AM Manish Goregaokar wrote: > Feature detection is often a pain point when figuring out why a site > doesn't work in Servo --

[dev-servo] Feature detector detector for Servo debugging

Feature detection is often a pain point when figuring out why a site doesn't work in Servo -- regular JS errors are logged and detectable, but feature detection is silent. JavaScript's awesome coercion rules cause similar issues when a property evaluates to false when it's really undefined. To