Hi,
On Wed, Feb 03, 2016 at 02:21:46PM -0500, Boris Zbarsky wrote:
> On 2/3/16 1:46 PM, Josh Matthews wrote:
> >https://github.com/servo/servo/wiki/Code-review
>
> Somewhere in there, one should read the commit messages too. Probably
> before reading the code. And if it's not clear from the
Hi,
On Tue, Apr 26, 2016 at 11:20:17AM -0700, Gregory Szorc wrote:
> The thing is, I'm not a huge fan of merge commits in version control,
> especially for large projects.
[...]
> All I'm asking is that Servo and its immediately related projects
> consider changing their ways.
Please don't.
Hi,
On Wed, Jun 22, 2016 at 09:57:22AM -0700, Bobby Holley wrote:
> In a bit more detail, there are basically 3 ways to manage CI:
> (1) The mozilla-inbound model (land possibly-untested stuff, run CI
> post-commit, perform backouts and close tree as necessary)
> (2) The bors/homu model (run the
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
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
>
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
> > >
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
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
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
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
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
Hi,
On Tue, Aug 09, 2016 at 08:17:47PM -0500, 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
> lead to PR
Hi,
On Thu, Sep 22, 2016 at 06:53:47PM -1000, Brian Smith wrote:
> Olaf Buddenhagen <olafbuddenha...@gmx.net> wrote:
> > Sorry for being late to this discussion, but I feel the need to remind
> > everyone of the infamous OpenSSL licensing problem, i.e. the fact that
&
Hi,
Sorry for being late to this discussion, but I feel the need to remind
everyone of the infamous OpenSSL licensing problem, i.e. the fact that
the SSLeay license it is (partially) covered by is considered
GPL-incompatible by many -- including (among others) the Debian project.
This affects not
Hi,
I'm leaving for a longish vacation. Can someone please take care of
https://github.com/servo/ipc-channel/pull/95 and
https://github.com/servo/ipc-channel/pull/90 before they bitrot? Thanks.
-antrik-
___
dev-servo mailing list
Hi,
On Wed, Nov 16, 2016 at 07:48:36PM +0100, Eddy Bruel wrote:
> To make IPC channels usable with Tokio, we'd have to take whatever low
> level IO primitive IPC channels use under the hood, and then reimplement
> the same logic that the existing IPC channels implement on top of this, but
>
16 matches
Mail list logo
