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

This reminds me of the original system I proposed for Rust back when it reached the point where PRs were coming in faster than we could test them. It's similar to what Michael proposed, though a bit more involved: https://gist.github.com/Manishearth/f2971973e164be03890a (yes, it does allude to

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

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 the green results you got and try again later. This doesn't scale to that

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

04.1000 < jgraham> I'm pretty sure every discussion I've ever seen of commit queues has ended with someone saying "we should binary search on the queue" 04.1000 < jgraham> I'm also pretty sure that zero times so far has anyone actually implemented that proposal :/ On Thu, Aug 4, 2016 at 11:45 AM

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

> 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." This is more or less the direction I've thought we'd move in as well. Basically try in bigger batches but have blame

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

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." * Approved Pull Requests (PRs) are pushed to the end of a queue as normal. They are marked as elligible for auto-rollup by

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

> My point is that I believe it's possible to create a setup doing full > pre-commit testing -- with all the advantages it brings over post-commit > testing -- while avoiding the scalability problems of the existing setup > is Servo. It depends what you mean by scalability. Doesn't pipelining the

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

On 04/08/16 12:24, Olaf Buddenhagen wrote: Hi, 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 one of the measures where Firefox is still vastly superior to the

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

On Wed, Aug 3, 2016 at 9:22 AM, Till Schneidereit wrote: > On Wed, Aug 3, 2016 at 5:35 PM, Jack Moffitt wrote: > >> I asked ekr how much this mattered, and he thought it was important. I >> don't think anyone has pointed me to a documented attack,

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

Hi, 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 one of the measures where Firefox is still > vastly superior to the competition, and I think we should aim for roughly

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

Hi, On Tue, Aug 02, 2016 at 04:33:12PM +0530, Manish Goregaokar wrote: > This sounds like a useful optimization; and it can be applied to the system > after it is set up. > > I believe that the autoland model works like this anyway, though I'm not > 100% sure. > > But we could do this on the

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

Hi, On Wed, Aug 03, 2016 at 10:53:39AM +0200, Till Schneidereit wrote: > I wonder to which extent this matters. I'm not aware of any real-world > instances of the mythical cross-tab information harvesting attack. Sure, in > theory the malvertising ad from one tab would be able to read