For 56.0b7 we need to implement a rule to upgrade 32 bit windows firefox users to 64 bit firefox if they are running on a 64 bit os. This watershed rule should be above the primary rule, for builds < b7, for users with > 2GB of RAM to get the 64bit beta. The release blobs will need to be updated to map the build target for 32bit firefox to 64 bit firefox for 64 bit OS. These release blobs can point to a separate release. We will also need QE to verify these rules during automation. For release we will need to implement a rule as well to with the same criteria with the addition of another criteria - mig64 - checking to see if they have been migrated before. Ben suggested that we could set up an example rule on Friday Aug 25 after b6 has shipped to verify that the data is correct for what we need to do next week.

/me has 64 bit Windows and even 4GB of RAM but is still not sure would get more good than harm from the transition (bug 1274659, comment 26) Couldn't you get to also take somehow into account average memory consumption of each user?

Attached json for special release based on b6. I wasn't sure if I should remove the non-windows release blobs or not. I just mapped the win32 release blobs to the win64 ones. Also I added a scheduled rule here https://aus4-admin.mozilla.org/rules/scheduled_changes The mapping is wrong, it will eventually point to the special release for b7 that I will create next week. Would appreciate feedback

Let me know if you want any more details or explanation on any of this - I know some of it isn't exactly obvious. (In reply to Kim Moir [:kmoir] ET from comment #2) > Created attachment 8901244 [details] > Firefox-56.0b6-watershed.json > > Attached json for special release based on b6. I wasn't sure if I should > remove the non-windows release blobs or not. I just mapped the win32 > release blobs to the win64 ones. Hmm, it doesn't look like anything is changed in this blob compared to Firefox-56.0b6-build2. It's not going to make a difference either way to leave or remove the Linux/Mac build targets - up to you about whether or not to leave them in. For Windows, you'll need to change the "WINNT_x86-msvc-x64" build target to alias to "WINNT_x86_64-msvc", and remove the partial MARs for the "WINNT_x86_64-msvc" platform (because they won't apply correctly). Using the release in its current form will serve 32-bit MARs to the users we want to upgrade. > Also I added a scheduled rule here > https://aus4-admin.mozilla.org/rules/scheduled_changes > > The mapping is wrong, it will eventually point to the special release for b7 > that I will create next week. > > Would appreciate feedback You're on the right track, The rule has a few things that need to be adjusted: - The priority needs to be lower. Because we'll be serving 56.0b7, we need to make sure the priority is lower than the most recent watershed (rule id 636, which has a priority of 140). - The memory field takes memory in megabytes. I asked about this last week, and ">2048" is what we want to ensure we don't update people with exactly 2GB of RAM. - The OS matching bits are pretty tricky. Instead of osVersion, buildTarget, and headerArchitecture, you can just use buildTarget. We only want to catch users running 32-bit Firefox on 64-bit Windows, which translates to "WINNT_x86-msvc-x64" as a buildTarget. Let me know if you want a more detailed explanation of this - I know it's not immediately obvious. - I suspect you know this already, but the buildid will also need to be updated once 56.0b7 is ready.

I updated the json and also the rule, feedback appreciated

(In reply to Kim Moir [:kmoir] ET from comment #4) > Created attachment 8901273 [details] > Firefox-56.0b6-watershed.json > > I updated the json and also the rule, feedback appreciated Looks good to me now!

screen shot of balrog rule setup, obviously channel, mapping and buildid are wrong and need to be updated with b7 info

From https://docs.google.com/document/d/1BRGNX47UDwo7L8W1YLII0YfZAdWdPuUeQvJ7C_SevwE/edit August 28 56.0b7 go-to-build! Rel Eng will create the cdn-test update channel for QA. Rel Eng need to configure update rules’ 64-bit minimum memory requirement to be strictly greater than 2 GB (“>2048” MB in Balrog). Andrei will execute the test plan using the 56.0b7 cdn test update channel. I assume the channel is really referring to means beta-cdntest

Script to automate munging the release blob, which you'd download from Balrog before running it. Removes all platforms except for win64, and the partials from win64, remaps the x86-on-x64 alias, fixes up the name, and we're ready to upload into Balrog. If we want to show a webpage after the update we could add action and openURL like we do for whatsnew page. For release anyway - we need the in-app version to change to trigger code logic in nsBrowserContentHandler.js. The version is static during a beta cycle.

Added Firefox-56.0b7-build2-win64-migration release to Balrog using attachment 8902074 [details]. Waiting for the automated update tests for 32->32 and 64->64 to complete before adding a rule for beta-cdntest.

Actually, the automated tests don't cover the 32 -> 64 case so the beta-cdntest has been rule is done.

Avaida reminded me that we also need a devedition rule on beta-cdntest so I'll add one.

I've added rule 644

Nick, can you sanity check the rule I added for aurora-cdntest?

From my note to release-drivers, qe requested I change the rules to include mig64=1 so I've done that To clarify, the mig64 parameter is supported in the beta-cdntest and aurora-cdntest watershed rules we setup as part of https://bugzilla.mozilla.org/show_bug.cgi?id=1393447#c0. However, right now the value is ignored in our watershed rules on these channels. From this bug it https://bugzilla.mozilla.org/show_bug.cgi?id=1386176 it looks like this value was included in 56.0b4 and the test plan doesn't go earlier than b4 to test the updates. I've updated the watershed rules for beta-cdntest and aurora-cdntest to check for a value of mig64=1

(In reply to Kim Moir [:kmoir] ET from comment #14) > Nick, can you sanity check the rule I added for aurora-cdntest? aurora and aurora-cdntest seem to have different priorities from equivalent rules on the beta channels. I suggest lowering the priority on rule 644 so it lies between 90 and 95 (from rule 637 for the lzma threshold, and rule 532 which points to latest). We should also remove rule 634 because it's a special case of 637.

Okay I have updated the rules on aurora-cdntest to reflect that, thanks Nick!

So Liz sent an email to release drivers We had some coordination/ communication issues for the 64-bit migration testing and release. For various reasons and time constraints, we are going to skip desktop beta 7. The earliest we could possibly release it is tomorrow morning in the U.S., but that would take up more QE time when we are already up against resource constraints. It seems best to skip Beta 7 for desktop beta and dev edition. For beta 8, we plan to go to build and release as usual, Thursday and Friday this week. (No migration.) "For beta 9, we will try again to get the 64-bit migration in place, on Monday and Tuesday next week. Chris is coordinating the new test plan for 64-bit migration along with kmoir and me. Because of the complexity of the migration, and the time consuming update testing, we would like to have the aurora-cdntest, beta-cdntest, release, and post-release update testing on aurora and beta to happen while QE in Romania is around to do the testing. So, it will make sense for me to hand off relman coordination for beta 9 to either gchang or jcristau, kim to hand off release duty to jlorenzo, and plan for Beta 9 release to happen Tuesday morning in Europe. Chris will follow up soon with a detailed testing plan and schedule." I'm attaching the rules I had pending for beta and aurora as reference for the rules that need to be enabled for 56.0b9.

I wrote some doc on how to enable the rules on Monday for b9 since it's a holiday in US/Canada. https://github.com/mozilla/releasewarrior/blob/master/how-tos/win32-win64-migration-balrog.md :jlorenzo let me know if my instructions are clear or require further info. THanks!

Thanks for these great piece of doc ! munge.py is so handy, we should write a similar script for "What's new" pages[1] :D The process makes sense to me, it's similar to a watershed for WNP. I have one quick question. I understood the client contained the logic to flip mig64 to 1, when the right conditions (like the OS) are matched[2]. We re-check the OS just for the sake of not trusting clients, right? [1] https://wiki.mozilla.org/Release:Release_Automation_on_Mercurial:Updates_through_Shipping#Set-up_whatsnew_page [2] https://hg.mozilla.org/releases/mozilla-beta/rev/3145c49cc4161881309672ebc275c36f4c9a36c9#l1.32

Glad that the documentation was helpful. Originally, the rules didn't include the check for mig64=1 for beta. Ben said that we didn't want that checked until release. But QE asked that we add that check after running their initial tests. I think that mig64 parameter was added on the client side around b4, but was just added to balrog a week or so ago. So that is the history of why that parameter is set in the rule. Originally when I set up the rules it was set to ignore, but QE requested it be checked as true.

Comment on attachment 8901273 [details] Firefox-56.0b6-watershed.json I think this request has outlived its usefulness.

This rule has been implemented in balrog on the Firefox beta channel as rule 650

I put Nick's algorithm (attachment 8902074 [details]) in the balrog helper Callek created in bug 1410121. Now, we have the ability to generate win64-blobs from Balrog directly. What do you think Callek?

Comment on attachment 8926837 [details] [diff] [review] [build/braindump] Bug 1393447 - Automate creation of win64 migration blob with completes r=Callek Review of attachment 8926837 [details] [diff] [review]: ----------------------------------------------------------------- I like it!

Script landed on braindump at https://hg.mozilla.org/build/braindump/rev/1cbcb486015ef2afee27229a91043f309e383f12

That patch cleans up the fileUrls block a bit more - removing partials from * and release-localtest sections, and removing the beta sections.

Comment on attachment 8927126 [details] [diff] [review] [build/braindump] Enhance blob creation Review of attachment 8927126 [details] [diff] [review]: ----------------------------------------------------------------- Good idea!

Comment on attachment 8927126 [details] [diff] [review] [build/braindump] Enhance blob creation https://hg.mozilla.org/build/braindump/rev/47d77a028ebe