Closed Bug 765871 Opened 13 years ago Closed 13 years ago

Please test 10.0.5 -> 14.0 (beta 7? RC?) migration one last time

Categories

(Firefox for Android Graveyard :: General, defect)

14 Branch
defect
Not set
normal

Tracking

(firefox14 fixed, blocking-fennec1.0 +)

VERIFIED FIXED
Tracking Status
firefox14 --- fixed
blocking-fennec1.0 --- +

People

(Reporter: akeybl, Assigned: nhirata)

Details

(Whiteboard: [no-code])

We need to test 10.0.5 -> 14.0 (beta 7? RC?) migration one last time.
blocking-fennec1.0: --- → ?
blocking-fennec1.0: ? → +
Keywords: qawanted
It's not clear what the best way to accomplish this is. Could we get a re-spin of beta 7 to get a signed build for internal testing?
I don't think you can upgrade org.mozilla.firefox -> org.mozilla.firefox_beta. We'd either need 2 special builds (a test 10.0.5 and a test 14.0, with the same branding + signing) or we'll need to create a release-signed release build (org.mozilla.firefox) that we don't intend to release. We can also potentially do a 14.0 build 1 as early as tomorrow, when we get go-to-build for beta 8. I'm not ready yet, but I can try to be; an early build 1 can help me find whatever issues there are in building a release build off beta, too.
(In reply to Aki Sasaki [:aki] from comment #2) > We can also potentially do a 14.0 build 1 as early as tomorrow, when we get > go-to-build for beta 8. I'm not ready yet, but I can try to be; an early > build 1 can help me find whatever issues there are in building a release > build off beta, too. Let's plan on this, and only do custom builds if we're not in position to build a 14.0 build 1 tomorrow. Thanks Aki!
(In reply to Aki Sasaki [:aki] from comment #2) > We'd either need 2 special builds (a test 10.0.5 and a test 14.0, with the same branding > + signing) This will be time consuming on my part, but doable. > or we'll need to create a release-signed release > build (org.mozilla.firefox) that we don't intend to release. Not recommended due to potential leak, but doable. > We can also potentially do a 14.0 build 1 as early as tomorrow, when we get > go-to-build for beta 8. I'm not ready yet, but I can try to be; an early > build 1 can help me find whatever issues there are in building a release > build off beta, too. This is problematic since it's off the same repo, dependent on the same mozconfigs, and the mozconfigs currently specify beta branding. More releasing-off-train issues. We could get go for beta 8, then approval for the mozconfig changes to official branding, then go for 14.0 build 1. If we have to do a beta 8 build 2 or a beta 9, we have to revert that change on mozilla-beta, then re-land it to do 14.0 build 2.
Spoke with Aki - we'll spin a build of FN14.0 off of the "release branch" of mozilla-beta whenever he's ready, and make sure to hide the directory soon after. I believe bug 758787 will need to be approved/land prior to the go-to-build.
Assignee: nobody → nhirata.bugzilla
Build received. initial testing of default xul current release to native build worked. Will test other configurations (ie w/ sync, w/ large bookmarks 2k+, w/ large history 2k+ )
During testing bug 766925, bug 766992, bug 766995 have been uncovered. All are probably won't fix? bug 766992 and 766995 are minor bugs.
(In reply to Naoki Hirata :nhirata from comment #7) > During testing bug 766925, bug 766992, bug 766995 have been uncovered. > All are probably won't fix? bug 766992 and 766995 are minor bugs. Thanks Naoki. Any reason that 10.0.4 was used instead of 10.0.5 in these tests?
I think I may have fat fingered 4 instead of 5 when typing the bug up? I used the build that was available on Google play.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Fixed the bug titles. Thanks for the catch.
removing QAwanted and marking as fixed for 14.
Keywords: qawanted
Setting this Verified/Fixed as a result of the above comments
Status: RESOLVED → VERIFIED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.