Wholeheartedly second this. It seems unusual for mozilla-inbound to actually be open, and then I get a rush of adrenaline trying to cram patches in before it closes again. I've forgotten about some patches for weeks because by I'd moved onto something else during a tree closure.

Really, I think the only way the current mozilla-inbound model can work is if someone goes through and checks in our patches for us (like pull requests), but that has its own problems and branch-specific work seems way better.

-David

On 12/12/2013 12: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

Reply via email to