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 browser work" and "JS
work" than between "JS non-jit work" and "JS jit work".
Kannan
On 12/12/2013, 3:32 PM, Jeff Walden wrote:
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
frustration for me. YMMV.
I think we should move back to a model where there is a separate tree
where JS patches land, which is periodically merged to
mozilla-central. JS patches tend to not conflict with patches in
other parts of the tree so this merging should be straightforward.
The only tree closures should be because of bustage in JS and
infrastructure issues.
Whatever the demerits of inbound, I don't think it's worth burning a bunch of
someone's (or everyone's) time to act as tree-shepherd to merge patches over
and mark bugs as fixed. If a solution doesn't involve that, I could be
receptive to it. (Although, I think you significantly underplay the
possibility of inbound/ourtree conflicts -- I remember them happening regularly
when we had the TM tree.)
Jeff
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
