457468 - Remove locale-specific subdomains from detailsURL in update snippets

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P3)

Description

[Reed Loden [:reed]]

Per bug 398938, we should remove the locale-specific subdomains from the detailsURL parameter in update snippets.

Example:
detailsURL="http://en-US.www.mozilla.com/en-US/firefox/2.0.0.17/releasenotes/"
... should be changed to:
detailsURL="http://www.mozilla.com/en-US/firefox/2.0.0.17/releasenotes/"

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

Reed, just to confirm, we're all set on the web side if I make this change now and it's used by the next set of releases ?

Comment 2

[Reed Loden [:reed]]

(In reply to comment #1)
> Reed, just to confirm, we're all set on the web side if I make this change now
> and it's used by the next set of releases ?

We've always supported not using the locale-based subdomains, but we've just preferred their use due to the notion that supposedly it would help with geodns, which just isn't true. Patch is pending review for Firefox to change the prefs, but again, it will work just fine if the locale-based subdomains from detailsURL are removed.

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Ok, assuming the same goes for 
 license = "http://%locale%.www.mozilla.com/%locale%/firefox/3.0/eula/index.html"
That's used for major updates only.

Comment 4

[Reed Loden [:reed]]

(In reply to comment #3)
> Ok, assuming the same goes for 
>  license =
> "http://%locale%.www.mozilla.com/%locale%/firefox/3.0/eula/index.html"
> That's used for major updates only.

Correct, that should be "http://www.mozilla.com/%locale%/firefox/3.0/eula/index.html" now... (though, not sure why you include the index.html there... could just do /eula/)

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: [checked in] Fix existing configs

I left the moz180 configs out since they are end of life like the builds.

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: [checked in] update patcher-config-bump.pl

Keeps configs fixed for future releases. I changed Bootstrap in case we don't get use the new script for the next set of 2.0.0.x and 3.0.x.

Comment 7

[[e-mail] (:bhearsum)]

Comment on attachment 341392 [details] [diff] [review]
[checked in] update patcher-config-bump.pl

Looks good, but how are you going to land the PatcherConfig.pm patch?

Comment 8

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #7)
> (From update of attachment 341392 [details] [diff] [review])
> Looks good, but how are you going to land the PatcherConfig.pm patch?

We should just ignore that, since I forgot to cvs up the file before patch creation.

Comment 9

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 341392 [details] [diff] [review]
[checked in] update patcher-config-bump.pl

rev: 29440980dcd2

Comment 10

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 341390 [details] [diff] [review]
[checked in] Fix existing configs

Checking in moz18-branch-major-update-patcher2.cfg;
/cvsroot/mozilla/tools/patcher-configs/moz18-branch-major-update-patcher2.cfg,v  <--  moz18-branch-major-update-patcher2.cfg
new revision: 1.7; previous revision: 1.6
done
Checking in moz18-branch-patcher2.cfg;
/cvsroot/mozilla/tools/patcher-configs/moz18-branch-patcher2.cfg,v  <--  moz18-branch-patcher2.cfg
new revision: 1.20; previous revision: 1.19
done
Checking in moz19-branch-patcher2.cfg;
/cvsroot/mozilla/tools/patcher-configs/moz19-branch-patcher2.cfg,v  <--  moz19-branch-patcher2.cfg
new revision: 1.42; previous revision: 1.41
done
Checking in moz191-branch-patcher2.cfg;
/cvsroot/mozilla/tools/patcher-configs/moz191-branch-patcher2.cfg,v  <--  moz191-branch-patcher2.cfg
new revision: 1.2; previous revision: 1.1
done

Comment 11

[Nick Thomas [:nthomas] (UTC+12)]

Some of this snuck back in because we're not using patcher-config-bump.pl for Fx2 & 3.0 yet

Comment 12

[Nick Thomas [:nthomas] (UTC+12)]

Depends on testing the scripts-in-hg from Bootstrap.

Comment 13

[Nick Thomas [:nthomas] (UTC+12)]

I looked at the snippets we have on disk to try to figure where we are with this. 

For Thunderbird, there are locale-specific domains used for only the 1.5.0.14 --> 2.0.0.14 major update.

For Firefox it's messier. Excluding test channels (betatest/releasetest), there are locale-specific domains for
* the 1.5.0.12 to 2.0.0.6 major update, the long-lived bridge between 1.5 and 2.0
* all the 2.0.0.x security release updates to 2.0.0.20
* 3.0.2 build5 to build6 bridge, where we went to the beta channel and then had to respin. We don't regenerate this path on every point release, really minimal number of users (if any!)
* for gu-IN on mac, 3.0b1-b4 updates to 3.0b5 then we stopped shipping gu-IN on mac

The only that might be worth fixing there is the 2.0.0.x minor update case, and we're good going forward because the release automation does the right thing (the second attachment here).

Comment 14

[Nick Thomas [:nthomas] (UTC+12)]

Going to close this out, reopen if you object strongly.