As someone who works mostly on the intersection of the JS engine and everything else, I'm not really wild about this. SpiderMonkey is pretty intimately tied to the rest of Gecko, certainly just as much as something like gfx. I think fx-team makes more sense, since most of the patches there consist primarily of changes to XUL/CSS/JS.
The main problem with inbound seems to be that it requires all developers, who are generally working on disjoint things, to devote attention to serializing their patches into inbound with other patches that are mostly unrelated (but might not be!). As the number of pushers and inbound closures increases, this becomes more and more of an attention-suck. The long-term solution that we're working towards is some kind of bugzilla-based auto-lander IIUC. But in the mean time, it seems like it would be trivial to write a locally-hosted (mach-integrated?) auto-lander script, the automates the process of: (1) Wait until inbound is open. (2) pull -u, apply the patches, and make sure they apply cleanly. (3) Push, and mark the bug. In the case where the patches don't apply, the developer can be alerted, since her attention is basically required in that case anyway. In all other cases, we effectively emulate the experience of pushing to an always-open inbound. This would be a relatively trivial tool to write, especially compared with the infra and staff burden of maintaining a bunch of separate repos. Thoughts? bholley On Thu, Dec 19, 2013 at 10:48 AM, Jason Orendorff <jorendo...@mozilla.com>wrote: > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
