On 7/11/16 10:10 PM, Gregory Szorc wrote:
I recommend not developing on top of inbound (or fx-team or autoland) and instead basing all work on central because:
This recommendation only works if your patches never depend on your own patches or on patches written by others you're working with, afaict.
> * pre-emptive notification in MozReview that 2 people are working on the same file(s) (there's a bug somewhere I think)
Happens _all the time_. Heck, often enough those 2 people are both me. ;)
Personally, I've been burned by inbound too much that I'll take rebase conflicts over tree instability almost any day.. YMMV. But inbound will eventually disappear, so you may want to start practicing living without it.
OK, so in the new world what is the right way to handle this situation (which I am in _all the time_, again):
I am working on three bugs, A, B, C. I write a patch for A and put it up for review. Then I write a patch for B, which depends on the patch for A, and put it up for review. Then the patch for A gets reviewed and I check it in and I'm also working on a patch for C.
Now where do I work on C? I had to update my tree to inbound to push A. I can rebase B on top of inbound (something I have to do anyway eventually) and start working on C on top of B. Or I can update to mozilla-central, but that doesn't have A.... so now what do I do with B and C? I can wait until A is merged over to mozilla-central and then start working on C, but that involves waiting for a day or three, which is not that great. I can go back to m-c and re-import the fix for A and then do B and C on top of that, I guess, but then I end up having to cherry-pick things when I want to commit B, right?
What's the envisioned workflow here in the autoland world? -Boris _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
