I don't have a horse in this race, but I have quite a bit of experience
managing trees in the past, so I'm going to list a number of downsides
to this proposal to hopefully help making a more informed decision.
1. js-inbound *will* be busted, and *will* be closed for bustage same as
any other tree. So it won't give you a 100% open tree.
2. Whether the js-inbound tree remains open more often than inbound
depends on how well it's sheriffed. For example, if you land a patch
which breaks the build and then 5 other people land on top of your
patch, each eith their own bustage, chances are than the bustage will
remain hidden until the offending patches are backed out one by one and
the tree remains closed to see whether the backout helped.
3. So, you will need someone to sheriff the tree. If that's the sheriff
team, then good for you! If not, it will be somebody on the JS team.
Remember that sheriffing can suck the joy out of your soul! ;-)
4. Adding another inbound will increase the chance of merge conflicts.
If you're *lucky*, you will detect the merge conflict at merge time
because hg would be mad at you. That's good, it's relatively easy to
deal with those kinds of conflicts. If you're unlucky, the merge
conflict will not happen at the source code level and you'll realize it
when a test which was green on both sides of the merge suddenly starts
to fail. Debugging those kinds of problems is extremely difficult,
especially since you often don't have any idea where to start, and you
won't always be able to reproduce the problem locally, and everybody
will be on your back because you're keeping all trees affected by your
merge indefinitely.
5. Source code level merge conflicts _will_ happen. Just because there
is a js-inbound tree, it doesn't mean that people will change their
behaviors. Those who occasionally touch js/src will continue to land
their stuff on other branches.
6. If the tree is sheriffed by somebody on the JS team, they will have
to deal with intermittent failures, etc.
Also, I'd like to urge you to please get in touch with our sheriffs to
let them know about this in advance even if you decide to sheriff this
tree yourself, as they will still be affected by this change.
Thanks, and happy hacking!
Ehsan
On 12/12/2013, 3:08 PM, Brian Hackett wrote:
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
