Closed Bug 459878 Opened 11 years ago Closed 11 years ago

Tracking bug: do major update from FF3.0.x to FF3.5 to make sure it all works

Categories

(Release Engineering :: General, defect, P3)

defect

Tracking

(status1.9.1 ?)

VERIFIED FIXED
Tracking Status
status1.9.1 --- ?

People

(Reporter: jbecerra, Assigned: nthomas)

References

()

Details

(Keywords: fixed1.9.1)

Attachments

(17 files)

4.98 KB, patch
coop
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
5.36 KB, patch
Details | Diff | Splinter Review
1.53 KB, text/plain
Details
1.41 KB, text/plain
Details
5.27 KB, text/plain
Details
3.47 KB, patch
ted
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
7.66 KB, patch
coop
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
1.81 KB, text/plain
Details
1.59 KB, text/plain
Details
3.62 KB, text/plain
Details
669 bytes, patch
Details | Diff | Splinter Review
8.13 KB, patch
bhearsum
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
1.38 KB, text/plain
Details
1.18 KB, text/plain
Details
2.22 KB, text/plain
Details
7.94 KB, patch
bhearsum
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
2.63 KB, text/plain
Details
We should generate a set of major updates prior to FF3.1 release, so QA has time to test and report problems before FF3.1 is shipped.
Yep, we did this for FF2->FF3.0, and it was very useful. (see bug#394046 for details).

Triaging to Future for now, until we get through some other stuff first.
Component: Release Engineering → Release Engineering: Future
Lets aim for 3.0.4 to 3.1b2, waiting for those releases.
Assignee: nobody → nthomas
Component: Release Engineering: Future → Release Engineering
Priority: -- → P3
Blocks: 470881
Gonna be from 3.0.5 to 3.1b2.
Status: NEW → ASSIGNED
Priority: P3 → P2
This adds a patcher config, and three verify configs, for a test major update. We'll never push release or beta channels live for this, just betatest and releasetest. The locale list for the verify configs is 3.0.5 less da, gl, ku, mk, mn, oc, sr, and th, based on diffing shipped-locales. Using CVS since we haven't switched Fx3.0.x releases over yet (need to verify all is well in bug 467310).
Attachment #355358 - Flags: review?(ccooper)
Attachment #355358 - Flags: review?(ccooper) → review+
Attachment #355358 - Flags: checked‑in+
I committed this followup fix for attachment 355358 [details] [diff] [review], as I'd 
* left out si and sl from the list of 3.0.5 locales in moz19-branch-major-update-patcher2.cfg
* hadn't tidied up the ja/ja-JP-mac per platform in update verify, so we were trying to test ja-JP-mac on linux and win32, and ja on Mac

Generated and tested the first time before these were landed.
win32 looks fine to me. The wikipedia-en-CN.xml searchplugin issue is already fixed, and Axel has a patch for the install.rdf/chrome.manifest issue up on bug 472431. --> No further action required on this platform, on this test.
Only a leftover libjemalloc.so is new here (compared to win32), since that moved into firefox-bin. We'll need to add that to removed-files.in.
Mac is, as ever, the problem child when it comes to packaging, because we don't control it with a manifest. There are 2 files, and 2 directories removed between 3.0 and 3.1 that need cleaning up.
This is against mozilla-central for baking there, with the goal to get it to mozilla-1.9.1 before 3.1b3 freezes. I'm hoping to test that the updater can handle the space in plugins/Default Plugin.plugin/ soon.
Attachment #357623 - Flags: review?(ted.mielczarek)
(In reply to comment #9)
> I'm hoping to test that the updater can handle the space in 
> plugins/Default Plugin.plugin/ soon.

This worked fine when I modified a partial update for a Shiretoko nightly - the update.manifest encloses the path in spaces. It does leave behind some empty dirs which the updater can't do anything about, but about:plugins reports only a Default Plugin with "File name: DefaultPlugin.plugin".
Attachment #357623 - Flags: review?(ted.mielczarek) → review+
This bug encompasses the prep. work to make sure we're able to offer a major update promptly when 3.1 is done. Requesting blocking for it.
Flags: blocking1.9.1?
Comment on attachment 357623 [details] [diff] [review]
Fix up removed-files.in and unix/packages-static (first run)

Baking on mozilla-central: http://hg.mozilla.org/mozilla-central/rev/501b8fce34fa
Works fine in my testing of mac and linux, and no bugs have been filed by nightly users. Ready for mozilla-1.9.1.
No longer blocks: 470881
Bugzilla is not configured for approval1.9.1 in this component, so CC beltzner for comment based approval. There has been no fallout filed against this patch, which removes files no longer in Firefox 3.1 when updating from 3.0.x.
(In reply to comment #14)
> Bugzilla is not configured for approval1.9.1 in this component, so CC beltzner
> for comment based approval. There has been no fallout filed against this patch,
> which removes files no longer in Firefox 3.1 when updating from 3.0.x.

Referring to attachment 357623 [details] [diff] [review] here.
(In reply to comment #14)
> Bugzilla is not configured for approval1.9.1 in this component, so CC beltzner
> for comment based approval.

That's because somebody messed up the original flag. I've fixed it. Request away!
Attachment #357623 - Flags: approval1.9.1?
Attachment #357623 - Flags: approval1.9.1? → approval1.9.1+
Comment on attachment 357623 [details] [diff] [review]
Fix up removed-files.in and unix/packages-static (first run)

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0fb1364ef059
Attachment #357623 - Flags: checked‑in+
We don't block on meta bugs; if there are unique issues, please nominate them.
Flags: blocking1.9.1? → blocking1.9.1-
Okie doke. 

Waiting for 3.1b3 now (--> P3 in the RelEng scheme)
Priority: P2 → P3
I also took a look at the 3.0.5 to 3.1b2 updates that Nick generated on all platforms and I did not find any problems.

I have noticed that using a profile with passwords saved in 3.1 doesn't have those passwords accessible in 3.0 so I assume we did something with how we save passwords in 3.1.
Yes. We're using mozStorage for passwords now (bug 288040), so FF3.0 won't see any passwords added in FF3.1.
Depends on: 480081
Blocks: 480417
No longer depends on: 480081
We'll generate a 3.0.7 to 3.1b3 test update as we get close to shipping 3.1b3.
Priority: P3 → P2
Bumps buildID's, locale lists (no change between 3.0.5 and 3.0.7; 3.1b2 to 3.1b3 is -cy and +da,fa,gl,ku,mk,mn,oc,sr,th,vi, but not all are available for 3.0.7), and switches d/l url to ftp.m.o to avoid lottery of mirror speed.
Comment on attachment 366479 [details] [diff] [review]
Update generation and verification configs for 3.0.7 --> 3.1b3

See comment #23 for notes on this patch
Attachment #366479 - Flags: review?(ccooper)
Promised QA that this would be ready for them Thursday.
Comment on attachment 366479 [details] [diff] [review]
Update generation and verification configs for 3.0.7 --> 3.1b3

fa and vi are missing from the platform major.cfgs, but I'm assuming that's because they're not in 3.0.x (according to comment 23 and a quick check of moz19-branch-major-update-patcher2.cfg).
Attachment #366479 - Flags: review?(ccooper) → review+
Comment on attachment 366479 [details] [diff] [review]
Update generation and verification configs for 3.0.7 --> 3.1b3

(In reply to comment #26)
> (From update of attachment 366479 [details] [diff] [review])
> fa and vi are missing from the platform major.cfgs, but I'm assuming that's
> because they're not in 3.0.x

Exactly. Given the time it to create patches with that sort of exception it's probably just easier to put in all 3.0.x locales and check failures after the verify completes.
Attachment #366479 - Flags: checked‑in+
3.0.7 --> 3.1b3 major update test is available on betatest channel. Automated checks are running and the first couple of locales look good.
Depends on: 483053
No big issues here, just a couple of locales with mucked up searchplugins (bug 483093, bug 483095).
No new problems since last time, and libjemalloc.so is fixed up.
No problems here, and we successfully fixed up a few issues.

No actions to take on packaging manifests this time. Will check 3.5b4pre a few days before code freeze to see if any files got removed but not in removed-files.in.
This is a better version of attachment 304252 [details] [diff] [review] - it recursively shows the contents of directories that diff reports with "Only in ...".
Priority: P2 → P3
hey nick, why was this tracking bug deprioritized to P3?
hey tony, there's nothing further for me to do at this moment (see comment #31). If you find any issues at this point it seems very likely they will be filed against Firefox itself.
And I probably should have said that P2/P3 mean something different for RelEng compared to Firefox/platform bugs. Roughly, P2 is working on it in the next week, P3 is longer term.
okay sounds good.  I thought RelEng's Px definitions would be different than devs, so i'm glad you clarified.
I compared en-US builds for 3.1b3 against today's nightlies. Files only found in one build are: 
* old-homepage-default.properties is only in the 3.1b3 builds via http://mxr.mozilla.org/mozilla1.9.1/source/other-licenses/branding/firefox/locales/Makefile.in#52
* linux nightly now has an updater.png from bug 473337
* mac nightly now has a components/necko_wifi.xpt from bug 479898 (shows up here because mac doesn't combine xpts like other platforms)

So nothing removed in nightlies that needs handling.
Going to refresh this for 3.0.10 to 3.5b4.
Priority: P3 → P2
In the update config: update versions and buildIDs, the locale list for 3.5b4, and use release copy of files in all locations. The "details" location isn't live yet, s/www/www-trunk.stage/ if you're curious. Going to ftp.m.o is a convenience for testing (avoiding slow mirrors) which will go away at 3.5 final.

In the verify config: update versions and buildIDs, add cy to locale list (we now have a 3.5 locale for every 3.0.x locale), switch to release location for "to" declaration. Sorry, I know this is a pain, it's easier if you use XCode's Filemerge (opendiff on the command line) between a pristine and patched copy of the files, it highlights the chars that changed.
Attachment #375982 - Flags: review?(bhearsum)
Comment on attachment 375982 [details] [diff] [review]
Update generation and verification configs for 3.0.10 --> 3.5b4

Everything looks good to me.
Attachment #375982 - Flags: review?(bhearsum) → review+
Comment on attachment 375982 [details] [diff] [review]
Update generation and verification configs for 3.0.10 --> 3.5b4

 Checking in moz19-branch-major-update-patcher2.cfg;
 new revision: 1.4; previous revision: 1.3
and 
 http://hg.mozilla.org/build/tools/rev/1dacbbe5613e
Attachment #375982 - Flags: checked‑in+
No problems here, just gl needing to fix up their searchplugin list still (bug 483093)
No problems for us to fix here, just gl searchplugins as noted above.
This is also fine.
Priority: P2 → P3
Summary: Tracking bug: do major update from FF3.0.x to FF3.1 to make sure it all works → Tracking bug: do major update from FF3.0.x to FF3.5 to make sure it all works
Al, do you want a 3.0.11/12 --> 3.5b99 test path set up ?
No. We only want to do this for the RC so, if the RC becomes the release, it will already be tested. We're snowed under with TB 2.0.0.22 right now so I expect that we will have an RC shortly after we're done.
r? for a sanity check. We lost mn and tr on the 3.5 branch, so we're going to get update verify errors there. Figured leaving the complete of 3.0.11 locales in the update verify was the best way forward.
Attachment #383873 - Flags: review?(bhearsum)
Look fine to me. We've removed deprecated searchplugins in the past but it's too late to do that for 3.5.
Attachment #383873 - Flags: review?(bhearsum) → review+
Attachment #383873 - Flags: checked‑in+
Comment on attachment 383873 [details] [diff] [review]
Update generation and verification configs for 3.0.11 --> 3.5rc2 build2

moz19-branch-major-update-patcher2.cfg: new revision: 1.5; previous revision: 1.4
build/tools: committed changeset 305:bb0bb3c44011

Note to self: Deliberately removed prettyVersion from 3.5rc2 block. We'll have to change this config if 3.5rc2 becomes 3.5 final, moving url to betatest-url and then url points to bouncer.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
if the work here is finished, could you please mark status1.9.1 accordingly? or fixed1.9.1 keyword at least. i'm querying bugzilla for unfinished 1.9.1 bugs and this is still marked as unfinished. or any other way to mark that we are done here, that i can query on.
status1.9.1: --- → ?
Keywords: fixed1.9.1
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.