Closed Bug 518408 Opened 10 years ago Closed 10 years ago
CE] Need to offer update snippets from Firefox 3 .6b2 to the b3
3.51 KB, patch
|Details | Diff | Splinter Review|
1.22 KB, patch
|Details | Diff | Splinter Review|
3.30 KB, patch
|Details | Diff | Splinter Review|
As discussed at the Firefox meeting today, we will need to offer beta updates to users who have the Firefox alpha2 build on Windows CE. Since we normally do not do this, this bug is to track this work and make sure it happens.
Summary: [WinCE] Need to offer update snippets from Firefox alpha 2 to the latest beta → [WinCE] Need to offer update snippets from Firefox 3.6 alpha 2 to the 3.6 latest beta
I'm pretty sure this is a RelEng task, unless I'm misreading it.
Component: Build Config → Release Engineering
Product: Toolkit → mozilla.org
QA Contact: build-config → release
Version: 1.9.2 Branch → other
Ted: Yes, sorry about the mistake. Nominating to make sure we don't lose sight of this.
This is on our radar. Taking for now.
Assignee: nobody → nthomas
Status: NEW → ASSIGNED
Marking P1 as we'll need to do this as part of the B1 release. Thanks for filing the bug, Marcia.
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P1
Hey Nick - how close to ready are we here? This isn't a code freeze blocker, obviously, but it is a B1 blocker, so I want to make sure we spot any problems early, if you foresee any.
Nick will have the definitive answer, but I don't think there's an action item here. As I understand it, snippets for 3.6a2 -> 3.6b1 will be generated as part of the 3.6b1 release, just like 3.6a1 -> 3.6b1 for the other platforms.
We'll have to generate a2 -> b1 snippets manually, and need some slight tweaks to our utilities to support that. All that work is in hand. Nothing needs to land in mozilla-1.9.2 prior to code freeze.
This is the sort of thing we'll need to do to the patcher config once it's been bumped for 3.6b1 on the traditional three platforms (modulo the staging host in betatest-url). Having only en-US in the 3.6b1 locales prevents patcher trying to download non-existent localized WinCE builds. The buildID obviously need fixing for the real value. We'd then do all the steps from 'patcher --download' in the updates factory, except for maybe the backupsnip.
Attachment #405220 - Attachment is obsolete: true
Nothing to do here until we ship a beta WinCE build.
Priority: P1 → P3
Much the same as the previous patches. Add set the correct from version, modify the partial filenames to use the right version, remove the past-update line which will confuse patcher, truncate the locales list to en-US, and add the buildid for wince-arm on 3.6b2. Planning to land this in CVS, generate updates and back it out.
10 years ago
Attachment #411340 - Flags: review?(joduinn) → review+
Comment on attachment 411340 [details] [diff] [review] patcher config change for 3.6a2-3.6b2 build1 WinCE updates Landing: Checking in moz192-branch-patcher2.cfg; /cvsroot/mozilla/tools/patcher-configs/moz192-branch-patcher2.cfg,v <-- moz192-branch-patcher2.cfg new revision: 1.10; previous revision: 1.9 done
Attachment #411340 - Flags: checked-in+
Comment on attachment 411340 [details] [diff] [review] patcher config change for 3.6a2-3.6b2 build1 WinCE updates Backed out after generating updates: Checking in moz192-branch-patcher2.cfg; /cvsroot/mozilla/tools/patcher-configs/moz192-branch-patcher2.cfg,v <-- moz192-branch-patcher2.cfg new revision: 1.11; previous revision: 1.10 done
Attachment #411340 - Flags: checked-in+ → checked-in-
No updates found on alpha 2 using releasetest channel. https://aus2.mozilla.org/update/3/Firefox/3.6a2/20090920154215/WINCE_arm-msvc/en-US/releasetest/Windows_CE%206.0/default/default/update.xml?force=1 GET /update/3/Firefox/3.6a2/20090920154215/WINCE_arm-msvc/en-US/releasetest/Windows_CE%206.0/default/default/update.xml?force=1 HTTP/1.1 Host: aus2.mozilla.org User-Agent: Mozilla/5.0 (Windows; U; WindowsCE 6.0; en-US; rv:1.9.2a2) Gecko/20090920 Firefox/3.6a2 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Cache-Control: no-cache Cookie: __utma=150903082.1043326428.1257617298.1257617298.1257884512.2; __utmz=150903082.1257617298.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); aus2a=10.2.84.100.1257647282.1116; __utmb=150903082 HTTP/1.x 200 OK Date: Tue, 10 Nov 2009 20:36:56 GMT Server: Apache/2.2.3 (Red Hat) X-Powered-By: PHP/5.1.6 Cache-Control: no-store, must-revalidate, post-check=0, pre-check=0, private Content-Length: 42 Keep-Alive: timeout=5, max=918 Connection: Keep-Alive Content-Type: text/xml;
juan, that's bug 527719.
Turns out that the patcher config wasn't updated when we did a 3.6a2 build2.
Attachment #411531 - Flags: review?(ccooper)
Attachment #411531 - Flags: review?(ccooper) → review+
Comment on attachment 411531 [details] [diff] [review] Fix 3.6a2 buildid Checking in moz192-branch-patcher2.cfg; /cvsroot/mozilla/tools/patcher-configs/moz192-branch-patcher2.cfg,v <-- moz192-branch-patcher2.cfg new revision: 1.12; previous revision: 1.11 done
Attachment #411531 - Flags: checked-in+
I was all set to close this as we had an update path from 3.6a2 to b2, but then bug 527867 came along and we had to pull it. I'm going to be working on automating WinCE update generation in bug 514305, so the manual work we've been doing here might get superceded before b3.
dolske, what do you want to do here given bug 527845 ? IIRC the updater.exe that executes is from the old build, so any WinCE build before 3.6b3 is destined to fail to update until the partner refreshes.
Mobile guys, please see comment #20.
I thought we replaced the updater as part of the initial step of the update? Rob Strong would know for sure.
Regretfully, the updater has never been updated first and then relaunched to apply the update. See bug 366846
(In reply to comment #20) > dolske, what do you want to do here given bug 527845 ? IIRC the updater.exe > that executes is from the old build, so any WinCE build before 3.6b3 is > destined to fail to update until the partner refreshes. Well, since it was on a pre-release OS image, the easiest thing to do is to just write it off and do nothing. That particular OS image isn't chipping to customers, afaik. If we *really* wanted to, we could tweak the MAR to not patch browserconfig.properties and... hmm... whatever the other file was. Or a custom update with just the updater. Not worth the effort, IMO.
Priority: P2 → P3
Summary: [WinCE] Need to offer update snippets from Firefox 3.6 alpha 2 to the 3.6 latest beta → [WinCE] Need to offer update snippets from Firefox 3.6b3 to the 3.6 latest beta/release
I don't see the benefit of having an open blocker for something which we (== RelEng) know is now part of our release process for 3.6. a2 -> b1 was ready to go but wasn't needed in the end, a2 -> b2 went live and was revoked, and we've successfully done b2 -> b3.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Summary: [WinCE] Need to offer update snippets from Firefox 3.6b3 to the 3.6 latest beta/release → [WinCE] Need to offer update snippets from Firefox 3.6b2 to the b3
verified fixed on WinCE 6.0 using Firefox 3.6b3 -> Firefox 3.6b4
Status: RESOLVED → VERIFIED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.