On 12/12/2013 12:22 PM, Sean Stangl wrote: > 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.
I've used that once or twice now too. > 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. No, we pay sheriffs these days to do this sort of thing. If we're going to get our own inbound, we want the sheriffs to manage it. Especially since we break our own tree very frequently, and I don't want to go back to the days of watching my own pushes for a few hours each. I mentioned reviving a JS inbound to the sheriffs a few months ago, and at that time they didn't think there was enough JS-specific breakage to make it worthwhile yet. (That's protecting others from us, not the other way around.) But things have gotten a lot worse since then. > 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. To be more specific, mozilla-inbound is a wildly successful experiment. It's way better than having to watch our own pushes and do our own merges. But the current partitioning of inbounds isn't scaling well enough for us. (There are a handful of inbounds -- mozilla-inbound, b2g-inbound, fx-team, not sure what else.) _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
