Closed
Bug 601895
Opened 14 years ago
Closed 14 years ago
Firefox 3.5.14 Build 3 incorrectly tagged
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: standard8, Assigned: bhearsum)
References
Details
I was just checking on revisions and found this in hg. From http://hg.mozilla.org/releases/mozilla-1.9.1/tags : FIREFOX_3_5_14_BUILD3 is a tag on revision dc338f6c00de FIREFOX_3_5_14_RELEASE is a tag on revision 9cabb92310de This is further confirmed in my manual tests: # hg update -r FIREFOX_3_5_14_RELEASE 360 files updated, 0 files merged, 14 files removed, 0 files unresolved # hg identify 9cabb92310de (GECKO19112_20100824_RELBRANCH) SEAMONKEY_2_0_9_BUILD1/FIREFOX_3_5_14_RELEASE/FIREFOX_3_5_14_BUILD1/SEAMONKEY_2_0_8_RELEASE/SEAMONKEY_2_0_8_BUILD1 # hg update -r FIREFOX_3_5_14_BUILD3 346 files updated, 0 files merged, 27 files removed, 0 files unresolved # hg identify dc338f6c00de (GECKO19114_20100930_RELBRANCH) SEAMONKEY_2_0_9_RELEASE/FIREFOX_3_5_14_BUILD3 I'm not sure what has gone on here or if it will affect the source tarball/builds/l10n repacks etc (I guess it depends if they pull the BUILD<n> tag or the RELEASE tag).
Assignee | ||
Comment 1•14 years ago
|
||
They pull _RELEASE. Looks like this is caused by the build2 tags happening on default, and hg being choosing tags on default over tags on a branch when in question. I think the fix is going to be removing the _RELEASE tag from both branches, and doing a build4.
Assignee: nobody → bhearsum
Assignee | ||
Comment 2•14 years ago
|
||
Oh, and for whatever reason, l10n repos seem unaffected: http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/zh-CN
Assignee | ||
Comment 3•14 years ago
|
||
Looks to have worked in my user repo: http://hg.mozilla.org/users/bhearsum_mozilla.com/mozilla-1.9.1/ (I pushed 3 commits; one removing FIREFOX_3_5_14_RELEASE from default, on removing it from the relbranch, and one that retagged dc338f6c00de as the _RELEASE tag -- on the relbranch). Will push the first two to the real repo and start the automation again.
Assignee | ||
Comment 4•14 years ago
|
||
Fixed in build4.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 5•14 years ago
|
||
So, after further investigation we discovered that despite the craziness you noticed with the tags, that build3 *did* in fact get built correctly as dc338f6c00de; this can be verified by downloading build3 and checking application.ini. I'm not 100% sure why you get the results you do in comment #0, but maybe it has something to do with full clone vs. incremental pull? hg's behaviour with tags is murky.
Resolution: FIXED → INVALID
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•