500442 - tracking bug for release of firefox 3.5 final

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[[e-mail] (:bhearsum)]

This bug serves to hold any patches we need (eg for tag and source generation) and other random things necessary while shipping 3.5.

Comment 1

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

Attachment: major update config for 3.0.11 --> 3.5 rc3

The main thing here is adding the url definition so that we serve all but betatest using bouncer. I wasn't sure if I should use the firefox-3.5rc3 product or just firefox-3.5 - the latter prevents releasetest QA until after we push to the mirrors. betatest still points to ftp.m.o for QA's convenience w.r.t. d/l speed. Otherwise version, locale, s/rc2/rc3/ bumps.

Comment 2

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

Attachment: major update config for 3.0.11 --> 3.5 rc3, v2

Same as before, except use a "firefox-3.5-complete" for the AUS product. Then we can (theoretically) distinguish between people who updated from 3.1/3.5 versions from those who came from 3.0.11.

Comment 3

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

Comment on attachment 385232 [details] [diff] [review]
major update config for 3.0.11 --> 3.5 rc3, v2

Checking in moz19-branch-major-update-patcher2.cfg;
new revision: 1.6; previous revision: 1.5

build/tools: committed changeset 308:a201448f7c13

Comment 4

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Added dep.bug to track controlling MU visibility.

Comment 5

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

Attachment: [followup] Use betatest channel for update verify

releasetest doesn't work until release day, use betatest instead.

committed changeset 309:8b0847bd0b4c

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: index.html with redirect to mozilla.com/firefox/comingsoon

When we seed to mirrors, we should include the following index.html file in the root of the mozilla.org/firefox/releases/3.5 directory. It includes a JS redirect to http://www.mozilla.com/firefox/comingsoon which thanks people for their interest, but asks them to wait until Tuesday and not download directly from the FTP site. For those with no Javascript, it carries a similar message.

Comment 7

[[e-mail] (:bhearsum)]

(In reply to comment #6)
> Created an attachment (id=385656) [details]
> index.html with redirect to mozilla.com/firefox/comingsoon
> 
> When we seed to mirrors, we should include the following index.html file in the
> root of the mozilla.org/firefox/releases/3.5 directory. It includes a JS
> redirect to http://www.mozilla.com/firefox/comingsoon which thanks people for
> their interest, but asks them to wait until Tuesday and not download directly
> from the FTP site. For those with no Javascript, it carries a similar message.


When we shipped 3.0 we also put this file in every subdirectory to try and prevent some deep linking. It's no trouble at all to do this again, shall we?

Comment 8

[[e-mail] (:bhearsum)]

Attachment: config bumps for tag & source for 3.5

We need to tag all the 1.9.1 repositories with FIREFOX_3_5_RELEASE, and also regenerate source packages so they contain that tag. With this patch, ReleaseTaggingFactory will tag the FIREFOX_3_5rc3_RELEASE revision with a FIREFOX_3_5_RELEASE tag. Note that in order to avoid creating a second relbranch I've set buildNumber to 2 (bug 500471 to fix that).

Once landed, the process here will be:
* Manually kick off tag
* Once tagging of mozilla-1.9.1 happens, manually kick-off source

The source builder will upload files to /pub/mozilla.org/firefox/nightly/3.5-candidates/build2 on stage, which I will quickly rsync to ~ffxbld and get rid of. From there they will be merged in with the rest of the firefox-3.5 directory and wait to be pushed to mirrors.

I've also filed bug 500473 to make sure we can do this in a simpler way next time.

Comment 9

[[e-mail] (:bhearsum)]

Comment on attachment 385739 [details] [diff] [review]
config bumps for tag & source for 3.5

changeset:   1240:3de487fa9024

Comment 10

[[e-mail] (:bhearsum)]

Comment on attachment 385739 [details] [diff] [review]
config bumps for tag & source for 3.5

I backed out the factory.py portion of this now that we're done.

changeset:   352:b9b14756b4b5

Comment 11

[[e-mail] (:bhearsum)]

Attachment: version bumps to 1.9.1.1pre/3.5.1pre

Comment 12

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

Comment on attachment 385841 [details] [diff] [review]
version bumps to 1.9.1.1pre/3.5.1pre

r+ for the intent. Please be sure to switch to the default branch before landing in mozilla-1.9.1.

Comment 13

[[e-mail] (:bhearsum)]

Comment on attachment 385841 [details] [diff] [review]
version bumps to 1.9.1.1pre/3.5.1pre

Checking in Firefox_mozilla-1.9.1.txt;
/cvsroot/mozilla/tools/tinderbox-configs/monitoring/Firefox_mozilla-1.9.1.txt,v  <--  Firefox_mozilla-1.9.1.txt
new revision: 1.10; previous revision: 1.9
done
Checking in XULRunner_mozilla-1.9.1.txt;
/cvsroot/mozilla/tools/tinderbox-configs/monitoring/XULRunner_mozilla-1.9.1.txt,v  <--  XULRunner_mozilla-1.9.1.txt
new revision: 1.4; previous revision: 1.3
done

changeset:   26036:dc0e69abb566

Comment 14

[[e-mail] (:bhearsum)]

shipped!

Comment 15

[Axel Hecht [:Pike]]

I'm wondering, why did you replace all entries in l10n-changesets?

Are there advantages? I see a few drawbacks, as in that it's hard to review updates to l10n-changesets like we need to make now for mk and sr, and it's using data that each localizer can even change locally in their repo.

Comment 16

[[e-mail] (:bhearsum)]

(In reply to comment #15)
> I'm wondering, why did you replace all entries in l10n-changesets?
> 
> Are there advantages? I see a few drawbacks, as in that it's hard to review
> updates to l10n-changesets like we need to make now for mk and sr, and it's
> using data that each localizer can even change locally in their repo.

I needed to change them to properly tag with FIREFOX_3_5_RELEASE. If it helps you out, I can revert to the 3.0rc3 version.

Comment 17

[Axel Hecht [:Pike]]

(In reply to comment #16)
> I needed to change them to properly tag with FIREFOX_3_5_RELEASE. 

Is there a bug on that? It's mostly breaking hg annotate and makes updates much harder than they should be.

> If it helps you out, I can revert to the 3.0rc3 version.

I'm currently trying to come up with a patch to l10n-changesets to bootstrap 3.5.1. I don't think that we should actually back out this changeset, but make the next patch hook up on the previous version and then merge. That way, there's at least a theoretical path to good diffs and history. Gonna file a bug on that shortly.

Another thing that I just noticed, we do have tags for the Beta builds of buildbot-configs, but not for the RCs and releases. Having l10n-changesets be tagged with the release info sounds worthwile, alongside with the rest of the build config.

Comment 18

[[e-mail] (:bhearsum)]

(In reply to comment #17)
> (In reply to comment #16)
> > I needed to change them to properly tag with FIREFOX_3_5_RELEASE. 
> 
> Is there a bug on that? It's mostly breaking hg annotate and makes updates much
> harder than they should be.
> 

Yeah, this one ;-). See comment #8.


> > If it helps you out, I can revert to the 3.0rc3 version.
> 
> I'm currently trying to come up with a patch to l10n-changesets to bootstrap
> 3.5.1. I don't think that we should actually back out this changeset, but make
> the next patch hook up on the previous version and then merge. That way,
> there's at least a theoretical path to good diffs and history. Gonna file a bug
> on that shortly.
> 

WFM.

> Another thing that I just noticed, we do have tags for the Beta builds of
> buildbot-configs, but not for the RCs and releases. Having l10n-changesets be
> tagged with the release info sounds worthwile, alongside with the rest of the
> build config.

Yeah, I agree. I've been meaning to get tools/configs/custom tagged along with everything else.

Comment 19

[Axel Hecht [:Pike]]

To get the tags out of l10n-changesets and update with the initial fixes is bug 502627.