The "checkin-needed" keyword is one way of dealing with mozilla-inbound
closures. (other than patches bitrotting, but people are pretty good at
landing keyword'ed patches)
Anyway, if the new branch were to happen, I'd suggest:
(1) not use a Monkey name, but rather js-inbound. This isn't a new JIT
Monkey.
(2) get the sheriffs to do the merging. (I definitely agree with sfink!)
One of the problems we've had with TraceMonkey being js-inbound was that
we had to periodically pester the js tree herder to do a merge landing
(dvander most of the time) before we start a new fuzzing run.
autoland has been dragged on due to various reasons, over the years, and
we probably shouldn't count on it until it is actually turned on.
-Gary
(cc'ing js-fuzzing folks too)
On 12/12/13, 2:43 PM, Steve Fink wrote:
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
