I think mozilla-inbound is a failed experiment. It seems like at
least half the time I try to land a patch, the tree is closed, usually
because of some issue unrelated to JS. When the tree reopens I need
to rush to get patches in before it recloses, which increases the risk
that patches cause
I second these experiences of working off m-i. Pushing patches manually is
randomly frustrating, and so I've been using the checkin-needed keyword to
avoid dealing with tree closures.
The only problem with our own JS branch is that we need to periodically merge
from m-c to JS. In the case of
On 12/12/2013 12:08 PM, Brian Hackett wrote:
I think mozilla-inbound is a failed experiment.
I don't fully agree, but I see the point.
Personally, I just buffer up patches when I want to push and inbound's closed.
Out of sight, out of mind temporarily is an easy enough way to avoid
Isn't part of the reason for that the fact that TraceMonkey (and with
Jaeger, Ion, and with Baseline, etc.) wasn't really a JS-specific tree?
They were jit-specific trees, and the jits generally have a lot of
cross-talk with the main JS VM.
I would expect far less overlap between general
On 12/12/2013 12:22 PM, Sean Stangl wrote:
I second these experiences of working off m-i. Pushing patches manually is
randomly frustrating, and so I've been using the checkin-needed keyword to
avoid dealing with tree closures.
I've used that once or twice now too.
The only problem with our
On 12/12/2013 12:45 PM, Kannan Vijayan wrote:
Isn't part of the reason for that the fact that TraceMonkey (and with
Jaeger, Ion, and with Baseline, etc.) wasn't really a JS-specific
tree? They were jit-specific trees, and the jits generally have a lot
of cross-talk with the main JS VM.
No
On 12/12/2013 12:45 PM, Kannan Vijayan wrote:
Isn't part of the reason for that the fact that TraceMonkey (and with Jaeger,
Ion, and with Baseline, etc.) wasn't really a JS-specific tree?
No, as sfink notes.
I would expect far less overlap between general browser work and JS work
than
On 12/12/2013 3:08 PM, Brian Hackett wrote:
I think mozilla-inbound is a failed experiment. It seems like at
least half the time I try to land a patch, the tree is closed, usually
because of some issue unrelated to JS. When the tree reopens I need
to rush to get patches in before it recloses,
I don't have a horse in this race, but I have quite a bit of experience
managing trees in the past, so I'm going to list a number of downsides
to this proposal to hopefully help making a more informed decision.
1. js-inbound *will* be busted, and *will* be closed for bustage same as
any other
Hi,
This is Haitao who is working with Niko, Dan and Ivan on SIMD128 API
(https://github.com/johnmccutchan/ecmascript_simd). Jandem pointed out
the similarity between Float32x4 (4 floats in a 128-bit SIMD register)
operations and Float32 optimization. After reading the Float32
optimization commit
Gary Kwong wrote:
autoland has been dragged on due to various reasons, over the years,
and we probably shouldn't count on it until it is actually turned on.
Taras is on the case, it'll happen now, I think.
Let's not make yet another repo if we can avoid it.
/be
On Thu, Dec 12, 2013 at 9:52 PM, Brendan Eich bren...@mozilla.com wrote:
Let's not make yet another repo if we can avoid it.
One more data point: I felt that killing off the tracemonkey repo was
a good move and made my life easier. Like bz, I work on a decent
number of patches that straddle
12 matches
Mail list logo
