For 3.6.2 build 2 the release automation ended up tagging the default branch with FIREFOX_3_6_2_RELEASE, which caused issues later on with l10n repacks. The release tagging should never be tagging revisions that aren't on a relbranch.
Created attachment 458307 [details] [diff] [review] Switch to relbranch Switch to relbranch without any condition.
Attachment #458307 - Flags: review?(catlee)
Comment on attachment 458307 [details] [diff] [review] Switch to relbranch Hmmm...How did 3.6.2 build2 end up tagging the default branch? Also, I think this will fail on build 1, since the new branch hasn't been really created yet.
Attachment #458307 - Flags: review?(catlee) → review-
Planning to fix this this quarter.
Assignee: nobody → bhearsum
Status: NEW → ASSIGNED
(In reply to comment #2) > Comment on attachment 458307 [details] [diff] [review] > Switch to relbranch > > Hmmm...How did 3.6.2 build2 end up tagging the default branch? > > Also, I think this will fail on build 1, since the new branch hasn't been > really created yet. For posterity, what happened here was that sourceRepoRevision was pointing at http://hg.mozilla.org/releases/mozilla-1.9.2/rev/827a6883442f in build2, so the tag commits were on the relbranch, but they pointed at a revision on default. So what we _really_ want to do here is add a check that verifies that the revision we're going to tag is on the relbranch that's been specified, when buildNumber > 1.
8 years ago
8 years ago
No longer blocks: 478420
bug 607372 added some verification that ensure we have the expected number of changesets on the relbranch/default. Therefore, this is FIXED by that.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.