Closed
Bug 428074
Opened 17 years ago
Closed 17 years ago
Tracking bug for Build and Release of FF3.0 RC1
Categories
(Release Engineering :: General, defect, P1)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: joduinn, Assigned: nthomas)
References
Details
Attachments
(5 files, 1 obsolete file)
2.05 KB,
patch
|
bhearsum
:
review+
|
Details | Diff | Splinter Review |
841 bytes,
patch
|
bhearsum
:
review+
|
Details | Diff | Splinter Review |
535 bytes,
patch
|
bhearsum
:
review+
|
Details | Diff | Splinter Review |
4.13 KB,
patch
|
bhearsum
:
review+
|
Details | Diff | Splinter Review |
684 bytes,
patch
|
nthomas
:
review+
|
Details | Diff | Splinter Review |
Placeholder bug, while we wait for development codefreeze.
Reporter | ||
Updated•17 years ago
|
Priority: -- → P3
Reporter | ||
Updated•17 years ago
|
Assignee | ||
Updated•17 years ago
|
Assignee | ||
Comment 1•17 years ago
|
||
Besides the normal checks for mozconfig and tinder-config divergence, we'll need to remember to change:
* in the en-US mozconfigs, use --enable-update-channel=release
* in mozilla/tools/patcher-configs/moz19-branch-patcher2.cfg, add "release" to channel declaration in the current-update block
Also noticed that we have this sort of thing
ac_add_options --enable-optimize="-Os -freorder-blocks -fno-reorder-functions -g
stabs+"
in both nightly and release mozconfigs for l10n. We moved to a plain --enable-optimize for en-US, so we should probably eliminate this for consistency. IIRC there aren't any executables created for the locales, except the setup.exe & helper.exe on win32 and those are NSIS apps (should check this).
Assignee | ||
Comment 2•17 years ago
|
||
Into setup mode we go, awaiting code freeze still.
Assignee: nobody → nrthomas
Priority: P3 → P2
Summary: Tracking bug for Build and Release of FF3.0.0 → Tracking bug for Build and Release of FF3.0 RC1
Assignee | ||
Comment 3•17 years ago
|
||
There wasn't anything to bring over from the nightly tinderbox configs, so this is just the switch to the release channel.
Attachment #318675 -
Flags: review?(bhearsum)
Updated•17 years ago
|
Attachment #318675 -
Flags: review?(bhearsum) → review+
Assignee | ||
Comment 4•17 years ago
|
||
Comment on attachment 318675 [details] [diff] [review]
[checked in] Switch to the release channel
Checking in release/linux/mozconfig;
/cvsroot/mozilla/tools/tinderbox-configs/firefox/linux/mozconfig,v <-- mozconfig
new revision: 1.2.2.11; previous revision: 1.2.2.10
done
Checking in release/macosx/mozconfig;
/cvsroot/mozilla/tools/tinderbox-configs/firefox/macosx/mozconfig,v <-- mozconfig
new revision: 1.3.2.8; previous revision: 1.3.2.7
done
Checking in release/win32/mozconfig;
/cvsroot/mozilla/tools/tinderbox-configs/firefox/win32/mozconfig,v <-- mozconfig
new revision: 1.3.2.11; previous revision: 1.3.2.10
done
Attachment #318675 -
Attachment description: Switch to the release channel → [checked in] Switch to the release channel
Assignee | ||
Comment 5•17 years ago
|
||
Sets the bootstrap tag to RELEASE_AUTOMATION_M9, and fixes up a step description I missed in bug 428063.
Attachment #318688 -
Flags: review?(bhearsum)
Updated•17 years ago
|
Attachment #318688 -
Flags: review?(bhearsum) → review+
Assignee | ||
Comment 6•17 years ago
|
||
Comment on attachment 318688 [details] [diff] [review]
[checked in] Update buildbot config
Checking in master.cfg;
/cvsroot/mozilla/tools/buildbot-configs/automation/production-1.9/master.cfg,v <-- master.cfg
new revision: 1.26; previous revision: 1.25
done
And master reconfiged (after a local mod to disable the nightly builds in training - but not shark or linux64).
Attachment #318688 -
Attachment description: Update buildbot config → [checked in] Update buildbot config
Assignee | ||
Comment 7•17 years ago
|
||
This picks up the three changes since RELEASE_AUTOMATION_M9
* fix regression in client.mk tag replacemet (attachment 319970 [details] [diff] [review])
* use the right version for the previous release in update verify (attachment 319983 [details] [diff] [review])
* teach GetOldVersion to return long names for RC's (attachment 319990 [details] [diff] [review])
We definitely need the first for 3.0 rc1 build1, the other two we want for 3.0 rc2 builds.
Attachment #320162 -
Flags: review?(bhearsum)
Updated•17 years ago
|
Attachment #320162 -
Flags: review?(bhearsum) → review+
Assignee | ||
Comment 8•17 years ago
|
||
Comment on attachment 320162 [details] [diff] [review]
[checked in] Update buildbot master to use RELEASE_AUTOMATION_M9_1
Checking in master.cfg;
/cvsroot/mozilla/tools/buildbot-configs/automation/production-1.9/master.cfg,v <-- master.cfg
new revision: 1.27; previous revision: 1.26
done
production-1.9-master updated.
Attachment #320162 -
Attachment description: Update buildbot master to use RELEASE_AUTOMATION_M9_1 → [checked in] Update buildbot master to use RELEASE_AUTOMATION_M9_1
Assignee | ||
Updated•17 years ago
|
Priority: P2 → P1
Assignee | ||
Comment 9•17 years ago
|
||
This needs the pull dates for tagging but should be otherwise complete.
Reporter | ||
Comment 10•17 years ago
|
||
From email with Axel:
>
> l10n pull date for RC1 is May 9th 10am PDT.
>
Assignee | ||
Comment 11•17 years ago
|
||
Summary of the changes here:
* Add current cutoff times for cvs (pullDate for /cvsroot might still change, updated from the WIP)
* use the new appVersion var to separate the name of the release (3.0rc1) from the version used in the app (3.0), from bug 428063. Also leave a comment so that we don't forget to set oldAppVersion when 3.0rc2 comes around.
* update the tag for patcherToolsRev to the latest (for 428063 & 428650)
* use dm-symbolpush01.mozilla.org for symbol upload as it's been reliable for nightlies and is the glorious future
Reminder of changes since we last did a release
* rc's are now called build's (bug 428063)
* no longer using the buildbot master as a staging server (bug 415970) so the externalStagingServer vars went away, and stagingServer/sshServer became stage-old.m.o
* another change in bug 415970 makes the slave copy the configured bootstrap config from the just-completed bootstrap checkout, rather than download it from the master. This means we no longer need to cvs update the bootstrap config on the master, but we do need to move the automation tag (since we do releases by pulling from a tag).
Attachment #320285 -
Attachment is obsolete: true
Assignee | ||
Updated•17 years ago
|
Attachment #320394 -
Flags: review?(bhearsum)
Updated•17 years ago
|
Attachment #320394 -
Flags: review?(bhearsum) → review+
Assignee | ||
Comment 12•17 years ago
|
||
Comment on attachment 320394 [details] [diff] [review]
[checked in] Update fx-moz19-bootstrap.cfg
Checking in fx-moz19-bootstrap.cfg;
/cvsroot/mozilla/tools/release/configs/fx-moz19-bootstrap.cfg,v <-- fx-moz19-bootstrap.cfg
new revision: 1.26; previous revision: 1.25
done
Moved RELEASE_AUTOMATION_M9_1 to rev 1.26
Attachment #320394 -
Attachment description: Update fx-moz19-bootstrap.cfg → [checked in] Update fx-moz19-bootstrap.cfg
Assignee | ||
Comment 13•17 years ago
|
||
"Back out bug 432938 because it caused bug 433241" moved the pullDate for to 2008-05-11 13:15 PDT. May also get another checkin for bug 433192 so waiting for a final timestamp before continuing.
Reporter | ||
Comment 14•17 years ago
|
||
Per email on dev.planning, now using pullDate of 2008-05-11 17:50 PDT for cvs repo.
The l10n change was landed in earlier patch. The only change here is the cvs repo cutoff time.
Attachment #320497 -
Flags: review?(nrthomas)
Assignee | ||
Comment 15•17 years ago
|
||
Comment on attachment 320497 [details] [diff] [review]
update bootstrap.cfg cutoff time for cvs repo
Checking in fx-moz19-bootstrap.cfg;
/cvsroot/mozilla/tools/release/configs/fx-moz19-bootstrap.cfg,v <-- fx-moz19-bootstrap.cfg
new revision: 1.27; previous revision: 1.26
done
Moved RELEASE_AUTOMATION_M9_1 to rev 1.27
Attachment #320497 -
Flags: review?(nrthomas) → review+
Assignee | ||
Comment 16•17 years ago
|
||
Resolving this bug, let's use a new one for a RC2 (if req'd).
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 17•17 years ago
|
||
Forgot to say that there's no version bump to be done if a RC2 is req'd, and we'll bump to 3.0.1pre if it isn't.
Updated•12 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•