Closed Bug 500442 Opened 11 years ago Closed 11 years ago

tracking bug for release of firefox 3.5 final

Categories

(Release Engineering :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: nthomas)

References

Details

Attachments

(5 files, 1 obsolete file)

This bug serves to hold any patches we need (eg for tag and source generation) and other random things necessary while shipping 3.5.
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.
Attachment #385209 - Flags: review?(bhearsum)
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.
Assignee: nobody → nthomas
Attachment #385232 - Flags: review?(bhearsum)
Attachment #385209 - Flags: review?(bhearsum)
Attachment #385209 - Attachment is obsolete: true
Attachment #385232 - Flags: review?(bhearsum) → review+
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
Attachment #385232 - Flags: checked‑in+
Added dep.bug to track controlling MU visibility.
Depends on: 500567
OS: Mac OS X → All
Hardware: x86 → All
releasetest doesn't work until release day, use betatest instead.

committed changeset 309:8b0847bd0b4c
Attachment #385301 - Flags: checked‑in+
Depends on: 500642
Depends on: 500663
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.
(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?
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.
Attachment #385739 - Flags: review?(ccooper)
Attachment #385739 - Flags: review?(ccooper) → review+
Comment on attachment 385739 [details] [diff] [review]
config bumps for tag & source for 3.5

changeset:   1240:3de487fa9024
Attachment #385739 - Flags: checked‑in+
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 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.
Attachment #385841 - Flags: review?(nthomas) → review+
Attachment #385841 - Flags: checked‑in+
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
shipped!
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
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.
(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.
(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.
(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.
To get the tags out of l10n-changesets and update with the initial fixes is bug 502627.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.