On Mon, Jul 11, 2016 at 6:53 PM, Nicholas Nethercote <n.netherc...@gmail.com > wrote:
> On Tue, Jul 12, 2016 at 2:27 AM, Jonathan Griffin <jgrif...@mozilla.com> > wrote: > > > > 2 - people sometimes push to try from bad heads (like a mozilla-inbound > push > > that will eventually get backed out) > > > > For 2, making sure you push to try only from the current tip of m-c will > > avoid this problem, or using MozReview's autoland to try, which will > > automatically do the same thing. > > There's a conundrum here: > > - It's natural to develop against m-i because that's where most people > land patches. > > - But you want to push to try against m-c because that's less likely > to have unrelated bustage. > I recommend not developing on top of inbound (or fx-team or autoland) and instead basing all work on central because: * inbound and fx-team will eventually go away (in favor of autoland) * tip of inbound is too unstable and you don't want to waste time developing against a bad base commit * autoland will soon have commit rewriting and attempting to pull from it will give you divergent heads and you'll have a really bad time (unless you are using Mercurial+evolve but even then tip of autoland has no stability guarantees) By working on central, you're trading the risk that tip is busted with the risk that your commit won't rebase cleanly onto tip of autoland. We can minimize that risk by: * "merging" autoland to central more frequently (the sheriffs are starting to do that and I'm working on tooling to do the merges as soon as they are ready) * pre-emptive notification in MozReview that 2 people are working on the same file(s) (there's a bug somewhere I think) * pre-emptive notification that your commits no longer rebase cleanly onto central or tip of autoland 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.
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
