Closed
Bug 644202
Opened 13 years ago
Closed 13 years ago
prep automation to merge mobile in
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mozilla, Assigned: mozilla)
References
Details
Attachments
(5 files, 4 obsolete files)
6.60 KB,
patch
|
coop
:
review+
mozilla
:
checked-in+
|
Details | Diff | Splinter Review |
561 bytes,
patch
|
catlee
:
review+
mozilla
:
checked-in+
|
Details | Diff | Splinter Review |
4.71 KB,
patch
|
bhearsum
:
review+
mozilla
:
checked-in+
|
Details | Diff | Splinter Review |
39.75 KB,
patch
|
catlee
:
review+
mozilla
:
checked-in+
|
Details | Diff | Splinter Review |
856 bytes,
patch
|
Pike
:
review+
mozilla
:
checked-in+
|
Details | Diff | Splinter Review |
There's a *lot* of assuming that a mobile build will have two repos. We need to make sure that when we merge mobile-browser into mozilla-central, nothing breaks.
Assignee | ||
Comment 1•13 years ago
|
||
We're going to hit a tbpl issue: we rely on the branch being mozilla-central-mobile-browser to differentiate mobile builds from desktop builds. Android and Maemo are one thing; win32/osx/linux fennec desktop builds may cause further confusion. How should we deal with this? One potential solution is don't split them in tbpl anymore; I'm leaning towards this one. Another is to pretend mobile-browser still exists, for tbpl purposes.
Assignee | ||
Comment 2•13 years ago
|
||
For Try, I'm thinking we're going to a) not have a mobile repo b) if you want to build a revision or release branch before the mobile-browser merge and you want mobile builds, you need to add mobile-repo and mobile-rev files.
Assignee | ||
Comment 3•13 years ago
|
||
For deb repos, I probably want a followup bug to be able to look at a URL for the locales list, rather than have to check out all of m-c for the one file.
Assignee | ||
Comment 4•13 years ago
|
||
This massive one-liner is all that's required in buildbot-configs so far. debsign/ is handled by mozharness. mozilla2/ and mozilla2-staging/ cover Fennec 1.x nightlies/incrementals/releases and 4.x releases and can be EOLed once Fennec 5.0 is out the door. Most of the heavy lifting/ugliness is in the next patch (buildbotcustom).
Assignee | ||
Comment 5•13 years ago
|
||
Comment on attachment 521397 [details] [diff] [review] configs diff Oh -- if we land this as is, it expects that all project branches also have mobile-browser merged in. That probably means there's going to be some tree burning, or we need to specify mobile_repo_path for each project branch and remove it whenever they merge from m-c.
Assignee | ||
Comment 6•13 years ago
|
||
This adjusts generateMobileBranchObjects() and adjusts MobileBuildFactory and its children to make mobileRepoPath optional. TODO: I need to revisit MobileBuildFactory's enable_try hg repo cloning steps. This will probably check for a mobile/ directory; if that doesn't exist, look for the mobile-repo file; if that doesn't exist, error out. I also tore out the unused MobileNightlyRepackFactory and its children; that's currently run by ScriptFactory. (Speaking of, nightly-mobile-repacks.py and nightly_mobile_repacks.sh probably need patching as well.)
Assignee | ||
Comment 7•13 years ago
|
||
I *think* this'll work. As with the buildbot-configs and buildbotcustom repos, we can live with some additional ugliness until Fennec 5 ships, and all moz+mob repo configurations are EOLed.
Comment 8•13 years ago
|
||
This patch makes the try logic the default for all builds that don't need a mobileRepoPath. This patch assumes that try will stop supporting separate locales on day one of the merge, but could be modified by adding an elif condition. The mobile: link is still printed, with the same revision as mozilla-central for legacy tools that may require both revisions for scraping. For builds that still have mobileRepoPath, nothing is changed
Attachment #521529 -
Flags: feedback?(aki)
Assignee | ||
Comment 9•13 years ago
|
||
Comment on attachment 521529 [details] [diff] [review] rip out the mobile directory when not needed Hm, maybe, if we change the mode='clobber' to 'update' if not self.enable_try. Allowing for the mobile_repo/mobile_rev files are actually needed until 4.0 is EOLed, however, so this patch needs work.
Attachment #521529 -
Flags: feedback?(aki) → feedback-
Comment 10•13 years ago
|
||
(In reply to comment #9) > Comment on attachment 521529 [details] [diff] [review] > rip out the mobile directory when not needed > > Hm, maybe, if we change the mode='clobber' to 'update' if not self.enable_try. sure > Allowing for the mobile_repo/mobile_rev files are actually needed until 4.0 is > EOLed, however, so this patch needs work. We don't support 1.9.2 on try right now aiui, I don't see why we would support mobile 4.0 on try. Anyway, the mobile_repo/mobile_rev files were try only, so it really shouldn't make any difference. If someone really does need to push to try with 4.0, they could use the mobile_rev and mobile_repo file on a pre-merge tree by doing something like: cd mozilla-central test -d mobile || hg clone http://hg.mozilla.org/`cat mobile_repo` mobile hg up -R mobile -r `cat mobile_rev` mv mobile/.hg mobile/.hg-old hg add mobile/* hg commit -m "Adding mobile for pushing to try" hg push -f ssh://hg.mozilla.org/try hg rollback hg forget mobile/* mv mobile/.hg-old mobile/.hg
Assignee | ||
Comment 11•13 years ago
|
||
* standard builds look good * l10n scripts need fixing * still need to revisit try
Assignee | ||
Comment 12•13 years ago
|
||
So I think the repack failed because it was looking in mobile/locales/l10n.ini, which is no longer at the top of an external repo anymore. I'm taking a stab at a mozilla-central/mobile/locales/l10n.ini, but I'm not sure if this will work.
Attachment #521735 -
Flags: feedback?(l10n)
Assignee | ||
Comment 13•13 years ago
|
||
The l10n.ini change isn't required for this to work, but will probably be needed for the l10n dashboard.
Attachment #521411 -
Attachment is obsolete: true
Assignee | ||
Comment 14•13 years ago
|
||
I added a check to see if there's a mobile dir, and if not, then require the mobile-repo rigmarole. This further complicates and uglifies the mobile checkout code, but we can tear all of this out once Fennec 5 ships and we EOL previous versions. I have tested the non-try portions of this patch; I need to test the try portion. This also has the fix from bug 629498.
Attachment #521403 -
Attachment is obsolete: true
Attachment #521529 -
Attachment is obsolete: true
Comment 15•13 years ago
|
||
Comment on attachment 521735 [details]
is this a good mobile/locales/l10n.ini ?
almost, drop the 'tld = mobile' line? That's also part of the one-off mobile logic.
Attachment #521735 -
Flags: feedback?(l10n) → feedback+
Assignee | ||
Comment 16•13 years ago
|
||
Comment on attachment 521748 [details] [diff] [review] tools v2: working l10n repacks My try testing went well. I'll flag these for review, and write up something about the merge logistics.
Attachment #521748 -
Flags: review?(bhearsum)
Assignee | ||
Updated•13 years ago
|
Attachment #521397 -
Attachment description: [untested] configs diff → configs diff
Attachment #521397 -
Flags: review?(catlee)
Assignee | ||
Updated•13 years ago
|
Attachment #522045 -
Attachment description: [untested] buildbotcustom patch with try → buildbotcustom patch with try
Attachment #522045 -
Flags: review?(catlee)
Assignee | ||
Updated•13 years ago
|
Attachment #521391 -
Flags: review?(coop)
Assignee | ||
Updated•13 years ago
|
Attachment #521391 -
Attachment description: [untested] mozharness diff → mozharness diff
Updated•13 years ago
|
Attachment #521391 -
Flags: review?(coop) → review+
Comment 17•13 years ago
|
||
Comment on attachment 521748 [details] [diff] [review] tools v2: working l10n repacks Just to make sure I understand fully: mobileBranch is kept, but made optional, in order to allow this to work for integrated and non-integrated style repacks?
Updated•13 years ago
|
Attachment #521397 -
Flags: review?(catlee) → review+
Updated•13 years ago
|
Attachment #522045 -
Flags: review?(catlee) → review+
Assignee | ||
Comment 18•13 years ago
|
||
(In reply to comment #17) > Comment on attachment 521748 [details] [diff] [review] > tools v2: working l10n repacks > > Just to make sure I understand fully: mobileBranch is kept, but made optional, > in order to allow this to work for integrated and non-integrated style repacks? Yes. 4.x builds off mozilla-2.1/mobile-2.0 will need a mobileBranch; these will be EOLed once Fennec 5.0 ships.
Updated•13 years ago
|
Attachment #521748 -
Flags: review?(bhearsum) → review+
Comment 19•13 years ago
|
||
(In reply to comment #1) > How should we deal with this? One potential solution is don't split them in > tbpl anymore; I'm leaning towards this one. Another is to pretend > mobile-browser still exists, for tbpl purposes. I don't have an opinion on this yet, I never use the Mobile tbpl. At the moment, failing mobile builds don't affect the Firefox tree state and don't keep people from checking in on mozilla-central, I think. Should they? To which Tinderbox will mobile builds report?
Assignee | ||
Comment 20•13 years ago
|
||
(In reply to comment #19) > (In reply to comment #1) > > How should we deal with this? One potential solution is don't split them in > > tbpl anymore; I'm leaning towards this one. Another is to pretend > > mobile-browser still exists, for tbpl purposes. > > I don't have an opinion on this yet, I never use the Mobile tbpl. At the > moment, failing mobile builds don't affect the Firefox tree state and don't > keep people from checking in on mozilla-central, I think. Should they? This is a larger discussion that should probably happen, but I'm going to step out on a limb and say yes, broken mobile builds should stop checkins on m-c. > To which Tinderbox will mobile builds report? Mobile currently, but we can change that as well.
Assignee | ||
Comment 21•13 years ago
|
||
Comment on attachment 521397 [details] [diff] [review] configs diff http://hg.mozilla.org/build/buildbot-configs/rev/b8508c777eeb
Attachment #521397 -
Flags: checked-in+
Assignee | ||
Comment 22•13 years ago
|
||
Comment on attachment 522045 [details] [diff] [review] buildbotcustom patch with try http://hg.mozilla.org/build/buildbotcustom/rev/119176006f3e
Attachment #522045 -
Flags: checked-in+
Assignee | ||
Comment 23•13 years ago
|
||
Comment on attachment 521748 [details] [diff] [review] tools v2: working l10n repacks http://hg.mozilla.org/build/tools/rev/5e6e3a8f3b74
Attachment #521748 -
Flags: checked-in+
Assignee | ||
Comment 24•13 years ago
|
||
Comment on attachment 521391 [details] [diff] [review] mozharness diff http://hg.mozilla.org/build/mozharness/rev/3b4e40e27fa7
Attachment #521391 -
Flags: checked-in+
Assignee | ||
Comment 25•13 years ago
|
||
We probably need followup bugs, which will probably include l10n.ini updating.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 26•13 years ago
|
||
Attachment #521735 -
Attachment is obsolete: true
Attachment #524315 -
Flags: review?(l10n)
Comment 27•13 years ago
|
||
Comment on attachment 524315 [details] [diff] [review] fix l10n dashboard r=me
Attachment #524315 -
Flags: review?(l10n) → review+
Assignee | ||
Comment 28•13 years ago
|
||
Comment on attachment 524315 [details] [diff] [review] fix l10n dashboard http://hg.mozilla.org/mozilla-central/rev/e6b318aca788
Attachment #524315 -
Flags: checked-in+
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
•