747347 - (elm-merge) Work - [Tracking] Migrate elm work over to mc and integrate win8 metro into fx desktop build/install

Status: RESOLVED FIXED

(Firefox for Metro Graveyard :: General, defect)

Description

[Jim Mathies [:jimm]]

This is a general marker bug for this task. Most of the work on elm has been filed under separate bugs within the "Windows 8 Metro" os. 

https://wiki.mozilla.org/Firefox/Windows_8_Integration#A_tentative_proposal

Comment 1

[Jim Mathies [:jimm]]

Attachment: new xre entry points v.1

Comment 2

[Jim Mathies [:jimm]]

Comment on attachment 620065 [details] [diff] [review]
new xre entry points v.1

Moving this to bug 750911.

Comment 3

[Ed Morley [:emorley]]

Sorry if this isn't the right place, but it's the closest bug I could find (having spotted mention of a future elm merge on the planning meeting wiki notes).

Jim, what's the plan with regards to landing the work in elm onto mozilla-central? Transplanting/cherrypicking or a direct merge? 

Main reason I ask is that the latter would bring with it ~1500 old changesets prior to elm's head being closed & it reset back to m-c tip, which we would need to avoid if at all possible. (This has probably all been thought through already - I just wanted to double check after something similar happening during webrtc's landing, that resulted in us having to strip changesets from a public repo and then deal with a bunch of mercurial infra fallout for days/weeks after)

Many thanks :-)

Comment 4

[Jim Mathies [:jimm]]

(In reply to Ed Morley [:edmorley UTC+0] from comment #3)
> Sorry if this isn't the right place, but it's the closest bug I could find
> (having spotted mention of a future elm merge on the planning meeting wiki
> notes).
> 
> Jim, what's the plan with regards to landing the work in elm onto
> mozilla-central? Transplanting/cherrypicking or a direct merge? 
> 
> Main reason I ask is that the latter would bring with it ~1500 old
> changesets prior to elm's head being closed & it reset back to m-c tip,
> which we would need to avoid if at all possible. (This has probably all been
> thought through already - I just wanted to double check after something
> similar happening during webrtc's landing, that resulted in us having to
> strip changesets from a public repo and then deal with a bunch of mercurial
> infra fallout for days/weeks after)
> 
> Many thanks :-)

The team discussed this. 

The early history of elm was purely experimental, and there are some hg copies from mobile down to browser/metro we would have preferred to be adds. So while we'll lose some useful check-in and mobile history we're going to do a transplanting/cherrypicking type merge culminating with a reset of elm at the end. 
 
Afterward elm will become our development repo, with regular mc <-> elm merges.

Comment 5

[Ed Morley [:emorley]]

(In reply to Jim Mathies [:jimm] from comment #4)
> So while we'll lose some useful check-in and mobile history we're going to
> do a transplanting/cherrypicking type merge culminating with a reset of elm
> at the end. 

That sounds great - thank you :-)

Comment 7

[Brian R. Bondy [:bbondy]]

Attachment: Sync widget interfaces

Here are some changes not yet in m-c from /widget but outside of /widget/windows/winrt

We can pull this into m-c whenever since MOZ_METRO isn't defined it'll have no effect on m-c today, just posting it here so we don't forget.

Comment 8

[Jim Mathies [:jimm]]

https://hg.mozilla.org/mozilla-central/rev/246c76621b80