On 28/06/2016 19:44, Gregory Szorc wrote:
Please follow bug 1266863 if you wish to track changes to the autoland repo
and our future plans to get rid of inbound, fx-team, merge commits, and
most backout commits in the final repo history (making mozilla-central
history linear without most bad/backed out commits).
That bug includes saying we're planning to rebase csets from the
autoland repo onto m-c. The rationale in that bug includes:
2) Merge commits make bisect harder than it needs to be
Which I would agree with. However, AFAICT the plan is to periodically
*rebase* a whole bunch of changes into mozilla-central from the autoland
repo rather than merging. I'm assuming we push all those rebased changes
in 1 go, instead of full-on doubling the time we spend building and
testing each revision...
The consequence of that would be that there's 1 push which gets 1 build
and the push can no longer be correlated to a merge cset and thereby a
particular range on the integration branch from which the csets came.
This is unfortunate given mozregression, which is basically 99% of all
the regressionhunting that gets done these days. m-c won't have builds
inbetween the csets that all got rebased and pushed in one go, and
there's no way to connect them up to integration branches when we're
using rebase. Even if there were, some csets will exist on the
integration branches but not on m-c. In principle, there's not even any
particular reason to suppose that the csets get landed on m-c in the
same order as on autoland, or that they are linear (if I'm reading the
'multiple heads' thing right).
In other words, in practice the proposed solution might actually make
bisection harder for people "on the ground" unless we do something. This
is especially the case because local rebuilds and clobber files really
hate each other, and clobber build times are still ridiculously high
(20-40 minutes depending on the platform) and so manually bisecting by
building revisions is really really painful and I avoid it at all costs.
What are we doing to solve this problem we're about to create?
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
