There have been several questions about the exact merge mechanics going from
mozilla-central –> aurora. While the specific problem is how to handle landing changes from mozilla-central into aurora, along with any possible changes already on aurora, I note that this can happen going from m-c –> aurora or from aurora –> beta or from beta –> releases. The general problem here is how to merge from an upstream repo that has changes into a downstream repo that has other possibly conflicting changes.

Many thanks to bz, catlee and ehsan for the great discussion over lunch last week. Let me know what you think, or if you see anything missing.

1. Never delete the aurora repo, we need the history.
2. Pull from m-c to a new head on aurora. Note exact changesets used, as this will be needed for next drop.
3. Query hg.m.o for list of changes since known changeset / tag of the previous drop.
4. Human needs to review list of changes since the last drop from m-c, and figure out which changes to bring forward, and which changes to throw away.
5. Use “hg transplant” to take the changes we want to bring forward and bring over to the new head.
6. Human needs to resolve any merge conflicts. Note: some specific files need careful human review of any changes, even if there are no merge conflicts. all.js, firefox.js, configure.in, mozconfig
7. Safety check:
   • Diff new-head-on-aurora vs m-c == list of all previous aurora backouts (smaller list?)
   • Diff new-head-on-aurora vs old-head-on-aurora == list of new code changes in m-c (bigger list?)
8. Mark the original head as closed, to prevent accidental landings on the wrong head.
9. Human needs to “hg push” back to aurora
10. All done.

Note: more details, alternate proposals, and some discussions can be found here in dev.planning newsgroup.