Sounds good to me too, but I think this branch will only be effective if all (regular) SpiderMonkey hackers push their patches to it, to avoid merge conflicts in js/src. Sheriffs already handle merges of m-i, b2g-inbound and fx-team, so they probably won't mind merging our branch as well. We should discuss this with them.
Jan On Thu, Dec 12, 2013 at 9:32 PM, Jeff Walden <[email protected]> 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
