On dev-tech-js-engine-internals, there's been some discussion about reviving a separate tree for JS engine development.
The tradeoffs are like any other team-specific tree. Pro: - protect the rest of the project from closures and breakage due to JS patches - protect the JS team from closures and breakage on mozilla-inbound - avoid perverse incentives (rushing to land while the tree is open) Con: - more work for sheriffs (mostly merges) - breakage caused by merges is a huge pain to track down - makes it harder to land stuff that touches both JS and other modules We did this before once (the badly named "tracemonkey" tree), and it was, I dunno, OK. The sheriffs have leveled up a *lot* since then. There is one JS-specific downside: because everything else in Gecko depends on the JS engine, JS patches might be extra likely to conflict with stuff landing on mozilla-inbound, causing problems that only surface after merging (the worst kind). I don't remember this being a big deal when the JS engine had its own repo before, though. We could use one of these to start: <https://wiki.mozilla.org/ReleaseEngineering/DisposableProjectBranches> Thoughts? -j _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
