The plan for the autoland repo is to rebase commits onto mozilla-central so we have a nice linear history. A downside of this rebasing is that mozregression, artifact builds, talos comparisons, and other tools that rely on the original commit SHA-1s get all confused. We need to come up with a sane way of handling this so as to not regress developer experience. I plan to eventually produce obsolescence markers saying how changesets are rebased. In theory, tools could query for precursor changesets and find the artifacts from the original changesets. It's a bit of work for each consumer, but doable. Another idea is to copy or "symlink" artifacts on archive.mo from the old changeset to the new. These would technically be lies since the artifacts really come from X' instead of X. But it is an elegant and simple solution (consumers won't need to care). Another idea is to trigger automation on mozilla-central for every original "push head" so that artifacts are reproduced on the new changeset. This would result in redundant work. But it would "just work" with existing tools and processes. I think we would only need to trigger build jobs (and possibly Talos jobs): no test jobs should be needed since commits shouldn't have made it to central if there were test failures. Assuming it is just build jobs, I /think/ we have the capacity to do this since our capacity problems are mostly testers these days. Preserving the "push heads" on central also has the benefit that, well, the push heads are preserved. That's something we miss with the straight rebase and something that's been bothering with the currently planned autoland repo approach. I'm tentatively going to say we should schedule builds on central for all the original push heads. Of course, we'll need to write some scheduling code that only runs builds and nothing else for all but the last push. And that means the scheduler needs a way to determine if a push head needs "partial" or "regular" automation. These are likely the hardest parts of this. I'm leaning towards Mercurial extension hackery to solve this problem.

Here is another idea: - if something busts the autoland integration branch, the branch is rewound to the last non-busted changeset, and the subsequent changesets are rebased on top of that, effectively removing the busted changeset/push. - non-busted states of the autoland integration branch are periodically merged to central.

(In reply to Mike Hommey [:glandium] from comment #1) > Here is another idea: > - if something busts the autoland integration branch, the branch is rewound > to the last non-busted changeset, and the subsequent changesets are rebased > on top of that, effectively removing the busted changeset/push. > - non-busted states of the autoland integration branch are periodically > merged to central. This isn't a bad idea (and something we may do instead of dealing with backout commits) except one of the key goals is to avoid merge commits in mozilla-central. So until the autoland repo is a "fast forward" of central, we can't do this trivially. Once inbound and fx-team go away, this option becomes available since there will be no commits on central that would warrant a merge.

I made a related comment in bug 1266863, I really think we should only ever rebase within integration branches. Also, I think we should only merge in integration branches, and on success, push to central. Not merging to central to begin with should remove a couple of merge commits already, I think.

Something else to keep in mind: once we aren't merging the autoland repo to mozilla-central, the changeset SHA-1s on the autoland repo will match mozilla-central. So if we remove the {{project}} component from artifact URLs, automation results from the autoland repo could share the same namespace with mozilla-central, allowing builds from any repo to "just work" with existing processes.