Re: How to merge from mozilla-central -> aurora

[Neil]

John O'Duinn wrote:
> 2) Pull from m-c to a new head on aurora. Note exact changesets used, as this will be needed for next drop.
Won't this want to pull on to the head created from the last pull that
you tried to close in step 8 last time?
> 3) Query hg.m.o for list of changes since known changeset / tag of the previous drop.
Is this not the same as doing hg incoming first, or have I misunderstood?

--
Warning: May contain traces of nuts.

[Ted Mielczarek]

On Mon, Apr 11, 2011 at 6:58 AM, Neil <ne...@parkwaycc.co.uk> wrote:
> John O'Duinn wrote:
>>
>> 2) Pull from m-c to a new head on aurora. Note exact changesets used, as
>> this will be needed for next drop.
>
> Won't this want to pull on to the head created from the last pull that you
> tried to close in step 8 last time?

I think the key here is to think of each head of Aurora like a
relbranch in our previous model. We'll pull m-c into Aurora, say
changeset XYZ winds up being the head. Then we land version
bumps/backouts/whatever else on top of XYZ, to make changeset XYZ123
the head, which winds up being Firefox 5 later down the road. Then,
when we're ready to take the next m-c pull, changeset XYZ will be the
common ancestor, with all the descendant changesets that landed on top
of it on m-c, with new head ABC. The head XYZ123 will be closed, and
ABC is the new head, rinse and repeat.

>> 3) Query hg.m.o for list of changes since known changeset / tag of the
>> previous drop.
>
> Is this not the same as doing hg incoming first, or have I misunderstood?

AFAICT, the point is to get all the changes that landed on top of the
previous common ancestor, so the descendants of XYZ in my previous
example.

-Ted

[Ted Mielczarek]

Hi John,

I drew up some diagrams in order to help myself understand this.
Hopefully I've understood your proposal and the diagrams are correct!
With annotations, below:

http://people.mozilla.com/~tmielczarek/m-c_to_aurora%201.png

1) First m-c -> aurora pull, aurora winds up as an exact clone of m-c,
with changeset D (present in both repositories) as the head.

http://people.mozilla.com/~tmielczarek/m-c_to_aurora%202.png

2) Backouts/disabling/etc landed on aurora (changesets Z, Y, X).
Changeset X is the new head of aurora.

http://people.mozilla.com/~tmielczarek/m-c_to_aurora%203.png

3) Development continues on m-c, with changesets E, F, G, H landed as
descendents of D.

http://people.mozilla.com/~tmielczarek/m-c_to_aurora%204.png

4) Next pull from m-c into aurora:
* Changesets E,F,G,H get pulled from m-c to aurora. Changeset H is the
new head of aurora.
* Human looks at list of landings from previous aurora head (Z, Y, X)
and determines that Z is needed
* Human transplants changeset Z to Z1 (as a descendant of H).
* Human closes previous head X on aurora.
* Backouts/disabling/etc landed on new head of aurora (changesets W,
V). Changeset V is the new head of aurora.

Am I correct in my understanding and representation? If so, this
doesn't look too far off from our existing release branch model, with
the exception that we're not using named branches.

Hope that was useful to someone besides myself,
-Ted

[L. David Baron]

On Monday 2011-04-11 01:46 -0700, John O'Duinn wrote:
> 7) Safety check:
> 7a) Diff new-head-on-aurora vs m-c == list of all previous aurora
> backouts (smaller list?)
> 7b) Diff new-head-on-aurora vs old-head-on-aurora == list of new code
> changes in m-c
> (bigger list?)

I think both of these diffs might be a little large for manual
review.

Another diff that's worth doing and which I think is more targeted
is the diff between:
* the new head to-be-pushed to aurora, and
* a merge (*not* to be pushed) between that head and the old head
on aurora.
This diff should show the backouts that were done on aurora for the
previous version that we're not moving forwards.

-David

--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/

[Benjamin Smedberg]

On 4/11/11 1:46 AM, John O'Duinn wrote:
> We recommend doing this:

> 8) Mark the original head as closed, to prevent accidental landings on
> the wrong head.
I would add 8b: add relevant tag(s) to help identify what happened. e.g.

AURORA_BASE_20110412 for the last mozilla-central change. Perhaps
additional tags for "after tranplanting relevant changes".

--BDS