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

VERIFIED FIXED

Status

defect
P3
normal
VERIFIED FIXED
11 years ago
6 years ago

People

(Reporter: jbecerra, Assigned: nthomas)

Tracking

({fixed1.9.1})

Dependency tree / graph
Bug Flags:
blocking1.9.1 -

Firefox Tracking Flags

(status1.9.1 ?)

Details

()

Attachments

(17 attachments)

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
Reporter

Description

11 years ago
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
Assignee

Comment 2

11 years ago
Lets aim for 3.0.4 to 3.1b2, waiting for those releases.
Assignee: nobody → nthomas
Component: Release Engineering: Future → Release Engineering
Priority: -- → P3
Reporter

Updated

11 years ago
Blocks: 470881
Assignee

Comment 3

11 years ago
Gonna be from 3.0.5 to 3.1b2.
Status: NEW → ASSIGNED
Priority: P3 → P2
Assignee

Comment 4

11 years ago
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+
Assignee

Updated

11 years ago
Attachment #355358 - Flags: checked‑in+
Assignee

Comment 5

11 years ago
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.
Assignee

Comment 6

11 years ago
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.
Assignee

Comment 7

11 years ago
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.
Assignee

Comment 8

11 years ago
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.
Assignee

Comment 9

11 years ago
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)
Assignee

Comment 10

11 years ago
(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+
Assignee

Comment 11

11 years ago
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?
Assignee

Comment 12

11 years ago
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
Assignee

Comment 13

11 years ago
Works fine in my testing of mac and linux, and no bugs have been filed by nightly users. Ready for mozilla-1.9.1.
Assignee

Updated

11 years ago
No longer blocks: 470881
Assignee

Comment 14

11 years ago
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.
Assignee

Comment 15

11 years ago
(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!
Assignee

Updated

11 years ago
Attachment #357623 - Flags: approval1.9.1?
Attachment #357623 - Flags: approval1.9.1? → approval1.9.1+
Assignee

Comment 17

11 years ago
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-
Assignee

Comment 19

11 years ago
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.
Assignee

Updated

11 years ago
Depends on: 480081
Blocks: 480417
Assignee

Updated

10 years ago
No longer depends on: 480081
Assignee

Comment 22

10 years ago
We'll generate a 3.0.7 to 3.1b3 test update as we get close to shipping 3.1b3.
Priority: P3 → P2
Assignee

Comment 23

10 years ago
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.
Assignee

Comment 24

10 years ago
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)
Assignee

Comment 25

10 years ago
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+
Assignee

Comment 27

10 years ago
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+
Assignee

Comment 28

10 years ago
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.
Assignee

Updated

10 years ago
Depends on: 483053
Assignee

Comment 29

10 years ago
No big issues here, just a couple of locales with mucked up searchplugins (bug 483093, bug 483095).
Assignee

Comment 30

10 years ago
No new problems since last time, and libjemalloc.so is fixed up.
Assignee

Comment 31

10 years ago
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.
Assignee

Comment 32

10 years ago
This is a better version of attachment 304252 [details] [diff] [review] - it recursively shows the contents of directories that diff reports with "Only in ...".
Assignee

Updated

10 years ago
Priority: P2 → P3
hey nick, why was this tracking bug deprioritized to P3?
Assignee

Comment 34

10 years ago
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.
Assignee

Comment 35

10 years ago
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.
Assignee

Comment 37

10 years ago
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.
Assignee

Comment 38

10 years ago
Going to refresh this for 3.0.10 to 3.5b4.
Priority: P3 → P2
Assignee

Comment 39

10 years ago
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+
Assignee

Comment 41

10 years ago
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+
Assignee

Comment 42

10 years ago
No problems here, just gl needing to fix up their searchplugin list still (bug 483093)
Assignee

Comment 43

10 years ago
No problems for us to fix here, just gl searchplugins as noted above.
Assignee

Comment 44

10 years ago
This is also fine.
Assignee

Updated

10 years ago
Priority: P2 → P3
Assignee

Updated

10 years ago
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
Assignee

Comment 45

10 years ago
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.
Assignee

Comment 47

10 years ago
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)
Assignee

Comment 48

10 years ago
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+
Assignee

Updated

10 years ago
Attachment #383873 - Flags: checked‑in+
Assignee

Comment 49

10 years ago
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.
Assignee

Updated

10 years ago
Status: ASSIGNED → RESOLVED
Closed: 10 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.
Assignee

Updated

10 years ago
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.