Closed Bug 568298 Opened 15 years ago Closed 15 years ago

support l10n-merge on firefox release factories

Categories

(Release Engineering :: General, defect, P2)

defect

Tracking

(blocking2.0 beta2+)

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta2+

People

(Reporter: Pike, Assigned: coop)

References

Details

(Whiteboard: [l10n][automation])

Attachments

(2 files, 2 obsolete files)

Given the sprint of betas, we'd like to have l10n-merge as an option for Firefox releases, as we do for Fennec already. Should be an option, just, really. Blocks Firefox 4 Beta program.
Priority: -- → P3
Whiteboard: [l10n][automation]
(In reply to comment #0) > Given the sprint of betas, we'd like to have l10n-merge as an option for > Firefox releases, as we do for Fennec already. > > Should be an option, just, really. I'm fine with this being an option for alphas and betas, but I don't think we'd ever want to use l10n-merge for an RC/release. Is that the consensus? Putting out a potentially half-translated release is unacceptable IMO.
Me, myself, and I all agree with you there. Team of four :-)
Can we have an ETA on this for this today's delivery meeting? This is a blocker for an aggressive beta program dance.
What's the progress here?
blocking2.0: --- → beta2+
Removing priority to get this back into the triage queue.
Priority: P3 → --
Assignee: nobody → ccooper
Severity: normal → major
Status: NEW → ASSIGNED
Priority: -- → P2
(In reply to comment #1) > (In reply to comment #0) > > Given the sprint of betas, we'd like to have l10n-merge as an option for > > Firefox releases, as we do for Fennec already. > > > > Should be an option, just, really. > > I'm fine with this being an option for alphas and betas, but I don't think we'd > ever want to use l10n-merge for an RC/release. Is that the consensus? Putting > out a potentially half-translated release is unacceptable IMO. (In reply to comment #2) > Me, myself, and I all agree with you there. Team of four :-) After some discussion within RelEng, we're proposing doing the following: 1) l10n-merge will be used for nightly, alpha builds 2) l10n-merge will be used for betas *only* when we know there will be another beta. However, l10n-merge will not be used for the last beta of a release, in order to reduce risk of surprises when doing RC. 3) l10n-merge will not used for RCs or any release builds Let us know if we're missing something?
Severity: major → normal
Priority: P2 → --
Nothing new. The interesting piece right now is that we have fx4 beta 2 code-freezing on Monday, and we'd love to put that out to l10n with l10n-merge on. What we do in later betas is something we should discuss in .planning, with the fx drivers and l10n drivers on board.
Priority: -- → P2
I have a patch written. I'll try to grab a staging env tonight to get it tested.
Falls back on the step from BaseRepackFactory which allows mergeLocale. Tested via staging runs of 4.0b2 with mergeLocales both on and off on moz2-master, which is still running on staging-master:9016 if you want to see the logs. Config changes upcoming.
Attachment #458139 - Flags: review?(nrthomas)
checkconfig fails if mergeLocales isn't specified (good thing), so we need to add it to all the release configs. I've opted to make it open-ended so we always have the option of putting out a release with mergeLocales on, but the default is off.
Attachment #458140 - Flags: review?(nrthomas)
(In reply to comment #10) > I've opted to make it open-ended so we always have the option of putting out a > release with mergeLocales on, but the default is off. Except for m-c in this case, or course, which we want to be running with mergeLocales for 4.0b2. Just saving a step here.
Comment on attachment 458139 [details] [diff] [review] Remove custom compareLocales from ReleaseRepackFactory >diff --git a/process/factory.py b/process/factory.py >- def compareLocales(self): >- self.addStep(ShellCommand, ... >- flunkOnWarnings=True, This is lost when we fall back to the copy in BackRepackFactory. I don't know if it makes sense to preserve it or not, but it would be worth checking if our expectations for nightlies are too loose when it comes to beta releases. r- because I think the patch is incomplete by not passing 'LOCALE_MERGEDIR=$PWD/merged' to 'make installers-%(locale)'. At least, that's the best I can figure out from the consistent failures in the make_installers_locale step, in your staging runs between Jul 17 13:59 and 14:39 where compare locales was run. And there's some problem with sync not being merged over, despite the include http://hg.mozilla.org/mozilla-central/file/default/browser/locales/l10n.ini
Attachment #458139 - Flags: review?(nrthomas) → review-
Comment on attachment 458140 [details] [diff] [review] Add mergeLocales to release configs >diff --git a/mozilla2-staging/release-fennec-1.0.py b/mozilla2-staging/release-fennec-1.0.py >+# mergeLocales allows missing localized strings to be filled in by their en-US >+# equivalent string. This is on (True) by default for nightly builds, but >+# should be False for releases *EXCEPT* alphas and early betas. If in doubt, >+# ask release-drivers. >+mergeLocales = False > productName = 'fennec' > appName = 'mobile' > mergeLocales = True You're changing an existing declaration of mergeLocales here and in the staging release-fennec-1.1.py. Please preserve the existing value. >diff --git a/mozilla2-staging/release-firefox-mozilla-1.9.1.py b/mozilla2-staging/release-firefox-mozilla-1.9.1.py >+mergeLocales = False > l10nRepoClonePath = 'releases/l10n-mozilla-1.9.1' Comment block & declaration got pasted twice into this file. Nit: align the ='s; same for mozilla2-staging/release-firefox-mozilla-1.9.2.py >diff --git a/mozilla2-staging/release-firefox-mozilla-central.py b/mozilla2-staging/release-firefox-mozilla-central.py >+binaryName = 'Firefox' >+oldBinaryName = 'MozillaDeveloperPreview' You should set |oldBinaryName = binaryName| for 4.0b2. Thanks for updating this to something more current. >diff --git a/mozilla2/release-fennec-1.0.py b/mozilla2/release-fennec-1.0.py >+# mergeLocales allows missing localized strings to be filled in by their en-US >+# equivalent string. This is on (True) by default for nightly builds, but >+# should be False for releases *EXCEPT* alphas and early betas. If in doubt, >+# ask release-drivers. >+mergeLocales = False > productName = 'fennec' > appName = 'mobile' > mergeLocales = False There's just duplication here, rather than the value changing in staging equvalent. Same for release-fennec-1.1.py. r+ with the comments fixed.
Attachment #458140 - Flags: review?(nrthomas) → review+
Does this need to be checked in before we roll builds?
Yes, but to build repo's rather than mozilla-central.
Whiteboard: [l10n][automation] → [l10n][automation][needs landing]
Blocks: 580010
(In reply to comment #12) > This is lost when we fall back to the copy in BackRepackFactory. I don't know > if it makes sense to preserve it or not, but it would be worth checking if our > expectations for nightlies are too loose when it comes to beta releases. I don't think so. The only other thing compareLocales does in BaseRepackFactory is remove an existing merged dir. > r- because I think the patch is incomplete by not passing > 'LOCALE_MERGEDIR=$PWD/merged' to 'make installers-%(locale)'. Fixed. Also, because I'm pedantic and have been staring at these steps for 4 days, I've changed the name/description to repack_installers across the board to be more consistent.
Attachment #458139 - Attachment is obsolete: true
Attachment #458668 - Flags: review?(bhearsum)
Comment on attachment 458668 [details] [diff] [review] Remove custom compareLocales from ReleaseRepackFactory, v2 Looks fine to me, based on Nick's prior review comment and your follow-up. r=me as long as your staging run passes.
Attachment #458668 - Flags: review?(bhearsum) → review+
Fixes the nits from nthomas in comment 13, and carrying forward the review.
Attachment #458140 - Attachment is obsolete: true
Attachment #458678 - Flags: review+
Comment on attachment 458668 [details] [diff] [review] Remove custom compareLocales from ReleaseRepackFactory, v2 http://hg.mozilla.org/build/buildbotcustom/rev/f406be13afb6
Attachment #458668 - Flags: checked-in+
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [l10n][automation][needs landing] → [l10n][automation]
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: