Closed Bug 727580 Opened 13 years ago Closed 13 years ago

mobile release configs for the 10esr branch

Categories

(Release Engineering :: General, defect)

ARM
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mozilla, Assigned: mozilla)

Details

(Whiteboard: [releases][android][automation])

Attachments

(3 files, 2 obsolete files)

This is now the plan of record. We may alter the version number ('esr' suffix or no 'esr' suffix) and the update channel to make things simpler for Socorro.
version 10.0.Xesr appVersion 10.0.X update channel esr For the latter, I think I need to create esr-specific mozconfigs for linux-android. Tempted to try to get android-xul working here so we can get rid of linux-android when 11.0 goes to mozilla-release. I also need to test my sign_android.py for mozilla-esr10 and mozilla-release builds.
(In reply to Aki Sasaki [:aki] from comment #1) > Tempted to try to get android-xul working here so we can get rid of > linux-android when 11.0 goes to mozilla-release. I think this is doable, but may be ugly if we make android-xul changes and inadvertently affect mozilla-esr10 without meaning to. The safest route is to keep linux-android going through the lifecycle of 10.0.X{,esr}, and just disabling it everywhere and explicitly enabling it on mozilla-esr10.
WIP patch queue: https://hg.mozilla.org/users/asasaki_mozilla.com/patches This started with a nuke mobile-desktop patch, which landed in bug 720774.
Attached patch (mozharness) esr10 configs (obsolete) — Splinter Review
This patch creates the esr10 configs in mozharness, with compare-locales pointing at RELEASE_0_8_2 for bug 713442. It also updates the release multilocale 'mozconfig' value to use the release mozconfig instead of nightly; we don't use this config setting at all, but it was bugging me. I successfully signed my previous staging release run (which triggered the 'all signed builds' email). I'm running a second, hopefully cleaner staging release as a final pre-review sanity check.
Previously this was specifying additional_locales, which means we'll look in the locales_file for the locales list and append 'en-US' and 'multi'. Now we're specifying the list of locales, no need to look anything up.
Attachment #600198 - Attachment is obsolete: true
Attached patch (configs) part 1 - 11.0 merge (obsolete) — Splinter Review
This patch needs to land when we merge 11.0 into mozilla-release. It removes linux-android and linux-android-debug from all branches but mozilla-esr10; it also removes all linux-android-debug mozconfigs.
This creates the mobile esr10 configs, l10n json, and mozconfigs.
Attachment #600220 - Flags: review?(rail)
Comment on attachment 600236 [details] [diff] [review] (configs) part 1 - 11.0 merge I think I'll volunteer for the next non-chemspill esr release =P
Attachment #600236 - Flags: review?(rail)
Comment on attachment 600239 [details] [diff] [review] (configs) part 2 - esr release configs + mozconfigs I've got a partial release at http://dev-master01.build.mozilla.org:8052/ ; I can leave that up if it helps you review.
Attachment #600239 - Flags: review?(rail)
Attachment #600239 - Flags: feedback?(bhearsum)
Comment on attachment 600239 [details] [diff] [review] (configs) part 2 - esr release configs + mozconfigs Review of attachment 600239 [details] [diff] [review]: ----------------------------------------------------------------- ::: mozilla/release-firefox-mozilla-esr10.py @@ +56,5 @@ > releaseConfig['l10nRepoPath'] = 'releases/l10n/mozilla-release' > releaseConfig['l10nRevisionFile'] = 'l10n-changesets_mozilla-esr10' > # Support repositories > releaseConfig['otherReposToTag'] = { > + 'build/compare-locales': 'RELEASE_0_8_2', Am I understanding bug 713442 correctly in that this will get reverted again at some point? The last comment there is over a month old.
Attachment #600239 - Flags: feedback?(bhearsum) → feedback+
(In reply to Ben Hearsum [:bhearsum] from comment #10) > ::: mozilla/release-firefox-mozilla-esr10.py > @@ +56,5 @@ > > releaseConfig['l10nRepoPath'] = 'releases/l10n/mozilla-release' > > releaseConfig['l10nRevisionFile'] = 'l10n-changesets_mozilla-esr10' > > # Support repositories > > releaseConfig['otherReposToTag'] = { > > + 'build/compare-locales': 'RELEASE_0_8_2', > > Am I understanding bug 713442 correctly in that this will get reverted again > at some point? The last comment there is over a month old. I think 3.6 and 10esr will stay on RELEASE_0_8_2, and when we bump RELEASE_AUTOMATION to a newer revision in bug 713442, they will remain unaffected. We of course have the option to move them together (or move them later), but this reduces risk.
Comment on attachment 600236 [details] [diff] [review] (configs) part 1 - 11.0 merge So I thought we were going to build 10esr when we built 11.0 release. We're actually going to go-to-build for 10esr next Friday. I'm going to have to split this up. Luckily, I think I have a version of this patch in my patch queue that doesn't do all of the 11.0 setup.
Attachment #600236 - Flags: review?(rail)
Running another staging release pass over the weekend. http://dev-master01.build.mozilla.org:8052/waterfall
Attachment #600236 - Attachment is obsolete: true
Comment on attachment 600598 [details] [diff] [review] linux-android for esr10, without merging 11.0 to m-r Looks good: http://dev-master01.build.mozilla.org:8052/one_line_per_build
Attachment #600598 - Flags: review?(rail)
Attachment #600220 - Flags: review?(rail) → review+
Attachment #600239 - Flags: review?(rail) → review+
Comment on attachment 600598 [details] [diff] [review] linux-android for esr10, without merging 11.0 to m-r Ship it! :)
Attachment #600598 - Flags: review?(rail) → review+
Comment on attachment 600220 [details] [diff] [review] (mozharness) esr10 configs, with locales specified http://hg.mozilla.org/build/mozharness/rev/78f514d1cab4
Attachment #600220 - Flags: checked-in+
Comment on attachment 600598 [details] [diff] [review] linux-android for esr10, without merging 11.0 to m-r http://hg.mozilla.org/build/buildbot-configs/rev/d9daaaacaf41
Attachment #600598 - Flags: checked-in+
Attachment #600239 - Flags: checked-in+
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
This went live this morning in the scheduled reconfiguration.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: