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 IonMonkey, this was taking dvander a significant amount of time on a near-daily basis, and we were eager to land just so we could stop dealing with merge conflicts. We could perhaps cycle through merge responsibility to avoid overtaxing any one individual. Sean ----- Original Message ----- From: "Brian Hackett" <[email protected]> To: "JS Internals list" <[email protected]> Sent: Thursday, December 12, 2013 12:08:15 PM Subject: [JS-internals] Reviving a JS specific tree 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 failures, need backouts, or cause closures, screwing things up for other developers. I find this process to be very stressful and a huge waste of time, and it is steadily sapping the enjoyment I get out of working on this browser. There are just too many developers competing to push patches to this tree. 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. Brian _______________________________________________ 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
