Create a project branch for Firefox "Lorentz"

RESOLVED FIXED

Status

RESOLVED FIXED
9 years ago
6 years ago

People

(Reporter: benjamin, Assigned: lsblakk)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(11 attachments, 19 obsolete attachments)

29.19 KB, patch
nthomas
: review+
Details | Diff | Splinter Review
29.27 KB, patch
nthomas
: review+
Details | Diff | Splinter Review
4.83 KB, patch
anodelman
: review+
lsblakk
: checked-in+
Details | Diff | Splinter Review
29.14 KB, patch
lsblakk
: checked-in+
Details | Diff | Splinter Review
29.78 KB, patch
lsblakk
: checked-in+
Details | Diff | Splinter Review
3.72 KB, patch
lsblakk
: review+
lsblakk
: checked-in+
Details | Diff | Splinter Review
33.89 KB, patch
nthomas
: review+
lsblakk
: checked-in+
Details | Diff | Splinter Review
2.34 KB, patch
nthomas
: review+
Details | Diff | Splinter Review
60.73 KB, patch
nthomas
: review+
coop
: review+
Details | Diff | Splinter Review
5.49 KB, patch
anodelman
: review+
lsblakk
: checked-in+
Details | Diff | Splinter Review
4.21 KB, patch
anodelman
: review+
lsblakk
: checked-in+
Details | Diff | Splinter Review
(Reporter)

Description

9 years ago
As discussed at the workweek and documented at https://wiki.mozilla.org/Talk:Firefox/Roadmap we would like a new project branch for landing and beta testing changes for Firefox "Lorentz", the stable release which is tentatively scheduled for Q1 2010.

This will branch from mozilla-1.9.2 and will contain fixes including out-of-process plugins and other features. We will want to do weekly betas from this branch starting the middle of January until release, which will, fingers crossed, occur in late March.

Project branch questionnaire:
* Do you want builds? Yes
** Which OS? All the OSes associated with 1.9.2, including WinMo and Maemo
** Incremental build-on-checkin: yes
** Nightlies: yes, *with nightly updates*... specific details need to be worked out, but bhearsum/nthomas said this might be possible if we called this Firefox 3.7a2 and bumped trunk to Firefox 4. The current plan is *not* to call this Firefox 3.7, though, so we'll need to figure something out.
** Are en-US builds enough: eventually, probably not, but for the first round yes. I'll file a followup to discuss how we need to deal with l10n.

* Do you want unittests: yes, to match the existing Firefox 3.6/1.9.2 tree.
* Do you want Talos: yes, to match the existing Firefox 3.6/1.9.2 tree.
* Name of branch owner: bsmedberg
** will do periodic merges from 1.9.2

* Timeline: start ASAP, expect the branch to be finished before April
** "Finish" means the branch will merge into 1.9.2

* Misc
** Any toolchain changes: we may need to use GCC 4.3 instead of GCC 4.1 on Linux. This is a simple mozconfig change which I can make at a later date. No other changes are expected.
** Tinderbox waterfall name: tinderbox.mozilla.org/Firefox-Lorentz
** Where to put builds on ftp.m.o: Firefox/latest-lorentz
** hg branch name: projects/firefox-lorentz
** unofficial project name: Lorentz
Assigning to John for prioritization.
Assignee: nobody → joduinn
Status: NEW → ASSIGNED
(In reply to comment #2)
> ** Nightlies: yes, *with nightly updates*... specific details need to be worked
> out, but bhearsum/nthomas said this might be possible if we called this Firefox
> 3.7a2 and bumped trunk to Firefox 4. The current plan is *not* to call this
> Firefox 3.7, though, so we'll need to figure something out.
Lets hold off on this for now. If possible, I dont want to do anything here which complicates future real releases. Nightly updates on project branches is a project in itself, not yet possible for any project branch. That work is being tracked in bug#534954. 

> ** Are en-US builds enough: eventually, probably not, but for the first round
> yes. I'll file a followup to discuss how we need to deal with l10n.
ok, so for now, no l10n.

> * Misc
> ** Any toolchain changes: we may need to use GCC 4.3 instead of GCC 4.1 on
> Linux. This is a simple mozconfig change which I can make at a later date. No
> other changes are expected.
aiui, nothing to do for now, but thanks for the headsup.
Assignee: joduinn → lsblakk
OS: Windows 7 → All
Created attachment 420656 [details] [diff] [review]
Add "lorentz" to staging configs
Attachment #420656 - Flags: review?(bhearsum)
Created attachment 420657 [details] [diff] [review]
Add "lorentz" to production configs
Attachment #420657 - Flags: review?(bhearsum)
We need the repo set up and the Firefox-Lorentz tinderbox page still. If no one has filed bugs for these, I can.
A couple questions:
* Do we need l10n? (eg, are we taking string changes on this branch?)
* What's the state of nightly updates? Are we keeping them off to start with?
Comment on attachment 420657 [details] [diff] [review]
Add "lorentz" to production configs

>+BRANCHES['lorentz']['repo_path'] = 'projects/firefox-lorentz'
>+BRANCHES['lorentz']['major_version'] = '1.9.2'

I don't think this is right - and it'll confuse 1.9.2 updates if set like this. Benjamin, do we know what the Gecko version is going to be yet?

>+BRANCHES['lorentz']['tinderbox_tree'] = 'Firefox-Lorentz'
>+BRANCHES['lorentz']['packaged_unittest_tinderbox_tree'] = 'Firefox-Lorentz'

This is staging, so I think you want MozillaTest

>+# Enable XULRunner / SDK builds
>+BRANCHES['lorentz']['enable_xulrunner'] = False

AIUI we're going to ship things from this branch, so let's flip it on.

>+BRANCHES['lorentz']['enable_l10n'] = False
>+BRANCHES['lorentz']['l10nNightlyUpdate'] = False 
>+BRANCHES['lorentz']['l10nDatedDirs'] = False 

Dunno if we're accepting string changes on this branch, but if we are we'll need l10n. Waiting on a response from Benjamin about this.

>+BRANCHES['lorentz']['aus2_base_upload_dir'] = 'fake'

We'll need something real for this eventually, but probably not today.


>diff --git a/mozilla2/mobile_config.py b/mozilla2/mobile_config.py

I'll look at this file, but I'd like Aki's review on it too.



>+### mobile-lorentz
>+MOBILE_BRANCHES['mobile-lorentz']['main_config'] = config.BRANCHES['lorentz']
>+MOBILE_BRANCHES['mobile-lorentz']['repo_path'] = 'projects/lorentz'

I think this should be firefox-lorentz.

>+MOBILE_BRANCHES['mobile-lorentz']['l10n_repo_path'] = 'l10n-central'

I don't think l10n-central is right - maybe l10n-mozilla-1.9.2?

>+MOBILE_BRANCHES['mobile-lorentz']['mobile_repo_path'] = 'mobile-browser'

Are we branching mobile-browser for this release, too? If we're not, I don't think we need another mobile branch at all!



Let's wait for Aki's review, and Benjamin to answer the followup questions I have, and give these another go.
Attachment #420657 - Flags: review?(bhearsum) → review?(aki)
Attachment #420656 - Flags: review?(bhearsum)
(Reporter)

Comment 9

9 years ago
The current plan is for the Gecko and Firefox version to be exactly the same as 1.9.2, because eventually this will just be 1.9.2.x/3.6.x. That plan is subject to change based on releng needs... we could certainly use a hacked-up version string on the branch such as 1.9.2.1plugins1 and 3.6.1plugins1 if that somehow makes releasing things easier during the branch lifetime.

There will be l10n changes on this branch, but it's not clear to me how that will work yet... we definitely don't want another set of l10n repositories, and the current l10n repositories may not gain the new strings for a bit yet. In any case, l10n-mozilla-1.9.2 is correct, not l10n-central.

Definitely not branching mobile-browser.
(In reply to comment #9)
> The current plan is for the Gecko and Firefox version to be exactly the same as
> 1.9.2, because eventually this will just be 1.9.2.x/3.6.x. That plan is subject
> to change based on releng needs... we could certainly use a hacked-up version
> string on the branch such as 1.9.2.1plugins1 and 3.6.1plugins1 if that somehow
> makes releasing things easier during the branch lifetime.

Okay. I haven't been able to dive into this enough to know what the best route is, so I'm going to have to let someone else (nthomas?) weigh in on that.

> There will be l10n changes on this branch, but it's not clear to me how that
> will work yet... we definitely don't want another set of l10n repositories, and
> the current l10n repositories may not gain the new strings for a bit yet. In
> any case, l10n-mozilla-1.9.2 is correct, not l10n-central.

Complicated....if we can guarantee we won't change any strings on the 3.6 builds that ship while Lorentz is branched we could just use the existing ones without issue. Dunno if that's possible though. (Also, if we do that we should turn off 1.9.2 nightly l10n and move it to the lorentz branch builders, since we don't need two sets of builds from those repos every night.
Comment on attachment 420657 [details] [diff] [review]
Add "lorentz" to production configs

Looks good.

Nit: trailing spaces at EOL after start_hour and start_minute.

Looks like these exist on other branches too... copy&paste at work.

Not important, but they sometimes bug me for no real good reason.
Attachment #420657 - Flags: review?(aki) → review+
(Reporter)

Updated

9 years ago
Blocks: 539055
Depends on: 539090

Comment 12

9 years ago
Maybe not latest-lorentz but latest-1.9.3?
(Reporter)

Comment 13

9 years ago
lorentz is not 1.9.3, please don't confuse things.

Comment 14

9 years ago
Why not 1.9.3? Current 3.7 nightly builds use 1.9.3a1pre platform

Comment 15

9 years ago
Azat, please read the bug and associated materials before commenting. (there are half a dozen "1.9.2"s in comment 0) The whole point of this thing is to port some features to 1.9.2 (roadmap is currently aiming for 1.9.2.2), namely the miracle that will be OOPP. 1.9.3 is a whole other thing.
We should put a tag in mozilla-1.9.2 at the clone point. How about FIREFOX-LORENTZ_BASE ?
(Reporter)

Comment 17

9 years ago
Why? We're going to merge regularly, so the base tag is probably not helpful.
I guess that was a knee-jerk response based on what we've done before, and with regular merging and a planned short lifetime it does seem less useful. We can always add it after the fact if necessary (on revision 05a4cc93f14b).
Created attachment 421361 [details] [diff] [review]
Add "lorentz" to production configs

Took out mobile since we're not branching that.  Turned the l10n on, took out extra space nit on start_hour and start_minute.
Attachment #420657 - Attachment is obsolete: true
Attachment #421361 - Flags: review?(bhearsum)
IMHO we should change
BRANCHES['lorentz']['l10n_tree'] = 'fx36x'
to be something distinct. 'lorentz' would work for me, but we'll have to copy the fx36x section over.

Is lorentz running on the same master as fx36x? Didn't check. gotta make sure that we're picking the right l10nbuilds.ini.
it can be run on the same master as fx36x
(In reply to comment #21)
> it can be run on the same master as fx36x

I don't think we should - pm01 is already crapping out from time to time. I don't think Axel is requesting that we run it in the same place, ftr, just making sure that the correct l10nbuilds.ini file is modified.
(In reply to comment #20)
> IMHO we should change
> BRANCHES['lorentz']['l10n_tree'] = 'fx36x'
> to be something distinct. 'lorentz' would work for me, but we'll have to copy
> the fx36x section over.

Do we know what the story is for l10n on Lorentz yet? As mentioned in comment #10, if we're using the existing 1.9.2 l10n repos for Lorentz we turn off the mozilla-1.9.2 branch l10n.
Comment on attachment 421361 [details] [diff] [review]
Add "lorentz" to production configs

This looks fine, but we still need to figure out the l10n story. Do you have a staging patch for this, too?
(Reporter)

Comment 25

9 years ago
If we have l10n builds, we'll be using the existing http://hg.mozilla.org/releases/l10n-mozilla-1.9.2. We will definitely not be branching the l10n repositories.
(In reply to comment #25)
> If we have l10n builds, we'll be using the existing
> http://hg.mozilla.org/releases/l10n-mozilla-1.9.2. We will definitely not be
> branching the l10n repositories.

So, these repositories will now (or soon) track Lorentz, rather than Firefox 3.6?
I don't agree with comment 10. We'll need l10n builds, including nightlies, to test the new strings. The basic idea is to require the strings for lorentz builds and expose them on the dashboard as such, but not require them for 1.9.2, and build against the 1.9.2 l10n repos. The Lorentz gecko code will have fallback strings to handle the case of not-updated localizations and language packs.

Might be best to track this in a follow-up bug, though.
(In reply to comment #26)
> So, these repositories will now (or soon) track Lorentz, rather than Firefox
> 3.6?

Both. Lorentz is Firefox 3.6.x, after all.
Comment on attachment 421361 [details] [diff] [review]
Add "lorentz" to production configs

I just talked through the l10n bits with Axel.

This is obvious to some, but just so it doesn't get lost:
We're going to be sharing the l10n-mozilla-1.9.2 repositories between firefox-lorentz and mozilla-1.9.2 for now. Lorentz is only making additive string changes, so those will not interfere with the existing mozilla-1.9.2 builds.

So, this patch is basically done, except you need to change 'l10n_tree' to be 'lorentz'.

Still need the buildbot-configs patch.
Duplicate of this bug: 496630
Created attachment 422376 [details] [diff] [review]
Add "lorentz" to production configs

this one has the mozconfigs in it (sorry I had forgotten to do hg add on the last patch) as well as the l10n_tree being "lorentz".
Attachment #421361 - Attachment is obsolete: true
Attachment #422376 - Flags: review?(bhearsum)
Attachment #421361 - Flags: review?(bhearsum)
Comment on attachment 422376 [details] [diff] [review]
Add "lorentz" to production configs

Didn't do a full review, but this lacks the change to l10nbuilds.ini, which of the two depends on the master, I guess. Not sure if this is actually hooked up to a master yet.
Created attachment 422379 [details] [diff] [review]
Add "lorentz" to production configs

just added lorentz to master2.cfg for pm02
Attachment #422376 - Attachment is obsolete: true
Attachment #422379 - Flags: review?(bhearsum)
Attachment #422376 - Flags: review?(bhearsum)
Created attachment 422381 [details] [diff] [review]
Add "lorentz" to production configs

now with l10nbuilds2.ini changes as well.
Attachment #422379 - Attachment is obsolete: true
Attachment #422381 - Flags: review?(bhearsum)
Attachment #422379 - Flags: review?(bhearsum)
Created attachment 422463 [details] [diff] [review]
Add "lorentz" to production configs

put the l10n and l10nbase back to 1.9.2 in l10nbuilds2.ini - my mistake there in attempting to create a new lorentz l10n repo.
Attachment #422381 - Attachment is obsolete: true
Attachment #422463 - Flags: review?(nrthomas)
Attachment #422381 - Flags: review?(bhearsum)
Comment on attachment 422463 [details] [diff] [review]
Add "lorentz" to production configs

I'm confused that there is no staging config here, what testing is being done on these changes ?

>diff --git a/mozilla2/config.py b/mozilla2/config.py

>+BRANCHES['lorentz']['major_version'] = '1.9.2'
>+BRANCHES['lorentz']['brand_name'] = 'Lorentz'

Random aside: these two don't even seem to be used anymore, which is good because we have m-c claiming to be 1.9.2 elsewhere. Lets ignore this.

>+BRANCHES['lorentz']['create_snippet'] = False
...
>+BRANCHES['lorentz']['l10nNightlyUpdate'] = True 
>+BRANCHES['lorentz']['l10nDatedDirs'] = True 

No point disabling en-US updates but enabling l10n ones, so flip the two l10n flags to False. We'll revisit this after we have en-US nightlies updating.

>+BRANCHES['lorentz']['platforms']['linux']['env'] = {
>+BRANCHES['lorentz']['platforms']['win32']['env'] = {
>+BRANCHES['lorentz']['platforms']['macosx']['env'] = {
These three env blocks need this added:
    'MOZ_SYMBOLS_EXTRA_BUILDID': 'lorentz',
to keep the nightly/release symbols separate from 1.9.2.

>+BRANCHES['lorentz']['platforms']['linux64']['env'] = {
Similarly this one should use
    'MOZ_SYMBOLS_EXTRA_BUILDID': 'linux64-lorentz',

>diff --git a/mozilla2/l10nbuilds2.ini b/mozilla2/l10nbuilds2.ini
>+mozilla = releases/lorentz

This should be 'projects/firefox-lorentz' as it's pointing to the repo.

>diff --git a/mozilla2/linux/lorentz b/mozilla2/linux/lorentz
>new file mode 100644
>--- /dev/null
>+++ b/mozilla2/linux/lorentz
>@@ -0,0 +1,1 @@
>+mozilla-1.9.2
>\ No newline at end of file
>diff --git a/mozilla2/linux64/lorentz b/mozilla2/linux64/lorentz
>diff --git a/mozilla2/macosx/lorentz b/mozilla2/macosx/lorentz

Are these proper symlinks ? When I tried to hg import this patch I just got a text file. For comparision, the file mode is 120000 when I create a symlink.

>diff --git a/mozilla2/winmo/mobile-lorentz/nightly/mozconfig b/mozilla2/winmo/mobile-lorentz/nightly/mozconfig
Should there be a mobile master config to go with this to provide WinMo and Maemo builds ?
Attachment #422463 - Flags: review?(nrthomas) → review-
Created attachment 422588 [details] [diff] [review]
Add "lorentz" to production configs

don't know what was up with the symlinks, redid them.  also am attaching the staging patch i used to test this configuration (i used my own repo for mozconfigs and got builds going too). thanks for pointing out the mobile_config being missing, I had it in staging and totally spaced on doing the change for production as well.
Attachment #422463 - Attachment is obsolete: true
Attachment #422588 - Flags: review?(nrthomas)
Created attachment 422589 [details] [diff] [review]
Add "lorentz" to staging configs
Attachment #420656 - Attachment is obsolete: true
Attachment #422589 - Flags: review?(nrthomas)
Created attachment 422624 [details] [diff] [review]
add "lorentz" to talos graphs db
Attachment #422624 - Flags: review?(anodelman)
Comment on attachment 422588 [details] [diff] [review]
Add "lorentz" to production configs

>diff --git a/mozilla2/config.py b/mozilla2/config.py

>+BRANCHES['lorentz']['create_snippet'] = False

FYI, even though this disables creation of mar files for nightlies, users will still find updates - back to the main mozilla-1.9.2 nightlies (need bug 534954).

>diff --git a/mozilla2/mobile_config.py b/mozilla2/mobile_config.py

The changes compared to the one aki r+'d (attachment 420657 [details] [diff] [review]) mostly seem fine, except for the builder names ...

>+MOBILE_BRANCHES['mobile-lorentz']['platforms']['linux-gnueabi-arm']['base_name'] = 'Maemo mozilla-lorentz'
>+MOBILE_BRANCHES['mobile-lorentz']['platforms']['linux-i686']['base_name'] = 'Linux Fennec Desktop mozilla-lorentz'
>+MOBILE_BRANCHES['mobile-lorentz']['platforms']['macosx-i686']['base_name'] = 'OS X Fennec Desktop mozilla-lorentz'
>+MOBILE_BRANCHES['mobile-lorentz']['platforms']['win32-i686']['base_name'] = 'Win32 Fennec Desktop mozilla-lorentz'
>+MOBILE_BRANCHES['mobile-lorentz']['platforms']['winmo-arm']['base_name'] = 'WinMo mozilla-lorentz'

Why 'mozilla-lorentz' here ? 'lorentz' would match up the other usage AIUI. r+ to fix that on checkin.
Attachment #422588 - Flags: review?(nrthomas) → review+
Comment on attachment 422589 [details] [diff] [review]
Add "lorentz" to staging configs

A few nits to fix on checkin for your r+.

>diff --git a/mozilla2-staging/config.py b/mozilla2-staging/config.py
>+BRANCHES['lorentz']['start_hour'] = [3] 
>+BRANCHES['lorentz']['start_minute'] = [32] 

Please remove trailing spaces to minimize difference between staging and prod.

>+BRANCHES['lorentz']['enable_xulrunner'] = False

This is True on prod. Since is staging is completely overwhelmed already lets keep staging and prod in sync by flipping it to True.

>+BRANCHES['lorentz']['enable_l10n'] = False
...
>+BRANCHES['lorentz']['enUS_binaryURL'] = \
>+    BRANCH_LEVEL_VARS['download_base_url'] + '/nightly/latest-lorentz'

L10n is enabled on production and there are some vars defined there but not here, so copy the equivalent section over.

>+BRANCHES['lorentz']['tinderbox_tree'] = 'MozillaTest'

Please add
BRANCHES['lorentz']['packaged_unittest_tinderbox_tree'] = 'MozillaTest'
Attachment #422589 - Flags: review?(nrthomas) → review+
Do we need talos master configs for this too?
Comment on attachment 422624 [details] [diff] [review]
add "lorentz" to talos graphs db

Incorrect os numbers associated with new builders.
Attachment #422624 - Flags: review?(anodelman) → review-
Created attachment 423061 [details] [diff] [review]
add "lorentz" to talos graphs db

fixed machine types
Attachment #422624 - Attachment is obsolete: true
Attachment #423061 - Flags: review?(anodelman)
Created attachment 423069 [details] [diff] [review]
Add "lorentz" to production configs (final)

nits addressed in this patch
Attachment #423069 - Flags: review+
Attachment #423069 - Flags: checked-in?
Created attachment 423070 [details] [diff] [review]
Add "lorentz" to staging configs (final)

nits addressed in this patch.
Attachment #423070 - Flags: checked-in?
Attachment #423069 - Flags: review+
Created attachment 423082 [details] [diff] [review]
add "lorentz" to talos buildbot-configs
Attachment #423082 - Flags: review?(anodelman)
Attachment #423082 - Flags: review?(anodelman) → review+
Attachment #423061 - Flags: review?(anodelman) → review+
Created attachment 423085 [details] [diff] [review]
add "lorentz" to talos buildbot-configs

took out release_tests and fetching release symbols
Attachment #423082 - Attachment is obsolete: true
Attachment #423085 - Flags: review?(anodelman)
Comment on attachment 423069 [details] [diff] [review]
Add "lorentz" to production configs (final)

http://hg.mozilla.org/build/buildbot-configs/rev/5d237ae06285
Attachment #423069 - Flags: checked-in? → checked-in+
Comment on attachment 423070 [details] [diff] [review]
Add "lorentz" to staging configs (final)

http://hg.mozilla.org/build/buildbot-configs/rev/6e8bb076aad2
Attachment #423070 - Flags: checked-in? → checked-in+
Attachment #423085 - Flags: review?(anodelman)
Attachment #423085 - Flags: review+
Attachment #423085 - Flags: checked-in+
Comment on attachment 423061 [details] [diff] [review]
add "lorentz" to talos graphs db

http://hg.mozilla.org/graphs/rev/c3e116abae05

alice/justdave added Lorentz to stage/prod graphserver
Attachment #423061 - Flags: checked-in+
bsmedberg: do we need wince builds for Lorentz?
(Reporter)

Comment 54

9 years ago
WinCE or winmo? AFAIK I do need winmo builds but probably not wince.
WinCE are "Firefox on WinCE" for tegra devices, WinMo is "Fennec on winmo".
'Linux lorentz build' and 'OS X 10.5.2 lorentz build' are red with:
  ======== BuildStep started ========
  Error: failed graph server post
  === Output ===
  results not added, response: 
  No branch_id for a branch_name 'Firefox-Lorentz' can be found

Looks like the branch added to the graphs db was 'Lorentz'.
I had to land a tiny bustage fix for mobile_config.py in staging: http://hg.mozilla.org/build/buildbot-configs/rev/0f468404a955
Depends on: 542024
(In reply to comment #56)
> 'Linux lorentz build' and 'OS X 10.5.2 lorentz build' are red with:
>   ======== BuildStep started ========
>   Error: failed graph server post
>   === Output ===
>   results not added, response: 
>   No branch_id for a branch_name 'Firefox-Lorentz' can be found
> 
> Looks like the branch added to the graphs db was 'Lorentz'.

This has been fixed now and builds are posting to graph server properly.

Unless there are further issues, I'll be closing this bug at the end of the day.
(Reporter)

Comment 59

9 years ago
I pushed something at 13:36 today and builds haven't kicked off yet:
http://hg.mozilla.org/projects/firefox-lorentz/pushloghtml
That could be an HgPoller issue with new repos. After the repo was cloned pushloghtml was empty, and so presumably was the pushlog RSS that buildbot was polling. Now it's querying http://hg.mozilla.org//projects/firefox-lorentz/pushlog?fromchange=e8f5e9c35f9ad7c70e95f716bd36bc0677a49507, so it knows there was a change pushed but for some reason didn't trigger builds on that. 

Could you try merging mrbkap's latest landing on m-1.9.2 to firefox-lorentz ?
(Reporter)

Comment 61

9 years ago
yep, new builds appeared with the second push
Created attachment 423436 [details] [diff] [review]
Fix for mozconfig paths and locations (staging and production) 

we use $repo to build the path to mozconfigs in the MercurialBuildFactory so the mozconfig path has to be "firefox-lorentz" not "lorentz". This patch adjusts both staging and production configs & file locations.
Attachment #423436 - Flags: review?(nrthomas)
Created attachment 423441 [details] [diff] [review]
Fix for mozconfig paths and locations (staging and production)

This time with the old and no longer usable "lorentz" mozconfigs removed.
Attachment #423436 - Attachment is obsolete: true
Attachment #423441 - Flags: review?(nrthomas)
Attachment #423436 - Flags: review?(nrthomas)
Comment on attachment 423441 [details] [diff] [review]
Fix for mozconfig paths and locations (staging and production)

>diff --git a/mozilla2-staging/config.py b/mozilla2-staging/config.py
>--- a/mozilla2-staging/config.py
>+# MercurialBuildFactory uses the repo_path in creating path to mozconfig so make sure they match 

As we discussed on IRC, please change this to (something like)
# UnittestBuildFactory uses repo_path to compute path the mozconfig for its old-style unit test
# builds, which forces the path for these opt and debug builds

Please also make sure that mozilla2*/win{32,ce}/lorentz are completely removed (either I'm importing the patch wrong or there's an empty lorentz/ tree still present).
Attachment #423441 - Flags: review?(nrthomas) → review+
http://hg.mozilla.org/build/buildbot-configs/rev/c6f68b110d44

with comment changed, and yes the lorentz folders were completely removed.
Attachment #423441 - Flags: checked-in+
Blocks: 542138
It looks like any related Lorentz requests have their own bugs so I'm closing this one.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Created attachment 423570 [details] [diff] [review]
[mobile_config.py] download_base_url was missing (I also did some clean up)

Are we to upload to /home/ftp/pub/*mobile*?

Including coop in reviews for ['winmo-arm']['create_snippet']
Attachment #423570 - Flags: review?(lsblakk)
Attachment #423570 - Flags: review?(ccooper)
Attachment #423570 - Flags: review?(aki)
Created attachment 423576 [details] [diff] [review]
 [mobile_config.py] download_base_url was missing (I also did some clean up) 

I attached an incorrect patch (missing some download_base_url)
Attachment #423570 - Attachment is obsolete: true
Attachment #423576 - Flags: review?(lsblakk)
Attachment #423576 - Flags: review?(ccooper)
Attachment #423576 - Flags: review?(aki)
Attachment #423570 - Flags: review?(lsblakk)
Attachment #423570 - Flags: review?(ccooper)
Attachment #423570 - Flags: review?(aki)
Created attachment 423577 [details] [diff] [review]
[mobile_config.py] download_base_url was missing (I also did some clean up) (v1)
Attachment #423576 - Attachment is obsolete: true
Attachment #423577 - Flags: review?(lsblakk)
Attachment #423577 - Flags: review?(ccooper)
Attachment #423577 - Flags: review?(aki)
Attachment #423576 - Flags: review?(lsblakk)
Attachment #423576 - Flags: review?(ccooper)
Attachment #423576 - Flags: review?(aki)
Comment on attachment 423577 [details] [diff] [review]
[mobile_config.py] download_base_url was missing (I also did some clean up) (v1)

we haven't moved from firefox/ -> mobile/ yet.
Attachment #423577 - Flags: review?(aki) → review-
Attachment #423577 - Flags: review?(lsblakk)
Attachment #423577 - Flags: review?(ccooper)
Created attachment 423628 [details] [diff] [review]
[mobile_config.py] download_base_url was missing (I also did some clean up) (v2)

Fixed aki's comment.
Attachment #423577 - Attachment is obsolete: true
Attachment #423628 - Flags: review?(lsblakk)
Attachment #423628 - Flags: review?(ccooper)
Attachment #423628 - Flags: review?(aki)
We need to reconfig Talos to pick up the new Lorentz builds. Downtime to be scheduled asap.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #423628 - Flags: review?(ccooper)
Attachment #423628 - Flags: review?(aki)
Created attachment 423637 [details] [diff] [review]
L10n path fix
Attachment #423637 - Flags: review?(nrthomas)
Attachment #423637 - Flags: review?(nrthomas) → review+
Created attachment 423684 [details] [diff] [review]
Rename of BRANCHES['lorentz'] to BRANCHES['firefox-lorentz'] in config.py (prod/staging)

So the shark builds were failing because the path to mozconfig is based on the branch name, and we moved all the mozconfigs from 'lorentz' to 'firefox-lorentz' because of unittest mozconfig path building which is based on repo name.

From now on, for all new branches, the repo_name must be the same as the BRANCHES['$name'] and the same as the mozconfig folder name.
Attachment #423684 - Flags: review?(aki)
Created attachment 423685 [details] [diff] [review]
Rename of BRANCHES['lorentz'] to BRANCHES['firefox-lorentz'] in config.py (prod/staging)

now with the Branches dictionary corrected to firefox-lorentz also.
Attachment #423684 - Attachment is obsolete: true
Attachment #423685 - Flags: review?(aki)
Attachment #423684 - Flags: review?(aki)
Created attachment 423687 [details] [diff] [review]
Rename of BRANCHES['lorentz'] to BRANCHES['firefox-lorentz'] in config.py (prod/staging)

added correction to Branch reference in master2.cfg as well as mobile_config.py
Attachment #423685 - Attachment is obsolete: true
Attachment #423687 - Flags: review?(nrthomas)
Attachment #423685 - Flags: review?(aki)
Created attachment 423690 [details] [diff] [review]
Rename of BRANCHES['lorentz'] to BRANCHES['firefox-lorentz'] in config.py (prod/staging)
Attachment #423687 - Attachment is obsolete: true
Attachment #423687 - Flags: review?(nrthomas)
Attachment #423687 - Attachment is obsolete: false
Attachment #423690 - Attachment is obsolete: true
Created attachment 423700 [details] [diff] [review]
Rename of BRANCHES['lorentz'] to BRANCHES['firefox-lorentz'] in config.py (prod/staging)

This patch applies cleanly and passes checkconfig on both staging and pm02 - it rolls in the clean up that Armen's patch did in order to do so.
Attachment #423628 - Attachment is obsolete: true
Attachment #423687 - Attachment is obsolete: true
Attachment #423700 - Flags: review?(nrthomas)
Attachment #423628 - Flags: review?(lsblakk)
Attachment #423700 - Flags: review?(nrthomas) → review?(aki)
Attachment #423700 - Flags: review?(aki) → review?(nrthomas)
Comment on attachment 423700 [details] [diff] [review]
Rename of BRANCHES['lorentz'] to BRANCHES['firefox-lorentz'] in config.py (prod/staging)

>diff --git a/mozilla2/mobile_config.py b/mozilla2/mobile_config.py

>+MOBILE_BRANCHES['mobile-trunk']['download_base_url'] = 'http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox'
>+MOBILE_BRANCHES['mobile-1.9.2']['download_base_url'] = 'http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox'
>+MOBILE_BRANCHES['mobile-tracemonkey']['download_base_url'] = 'http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox'
>+MOBILE_BRANCHES['mobile-lorentz']['download_base_url'] = 'http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox'

These should be http://stage.mozilla.org/... for production, I think. r+ to fix that on checkin if coop r+'s too
Attachment #423700 - Flags: review?(nrthomas)
Attachment #423700 - Flags: review?(ccooper)
Attachment #423700 - Flags: review+
Attachment #423700 - Flags: review?(ccooper) → review+
Depends on: 542411
Created attachment 424144 [details] [diff] [review]
Talos configs - lorentz -> firefox-lorentz
Attachment #424144 - Flags: review?(anodelman)
Created attachment 424145 [details] [diff] [review]
Talos graphs/data.sql - lorentz -> firefox-lorentz
Attachment #424145 - Flags: review?(anodelman)
Created attachment 424147 [details] [diff] [review]
Talos graphs/data.sql - lorentz -> firefox-lorentz

re-did patch with proper platform codes.
Attachment #424145 - Attachment is obsolete: true
Attachment #424147 - Flags: review?(anodelman)
Attachment #424145 - Flags: review?(anodelman)
Attachment #424144 - Flags: review?(anodelman) → review+
Attachment #424147 - Flags: review?(anodelman) → review+
Comment on attachment 424147 [details] [diff] [review]
Talos graphs/data.sql - lorentz -> firefox-lorentz

http://hg.mozilla.org/graphs/rev/4bc13bf26989
Attachment #424147 - Flags: checked-in+
Well the naming conflicts between lorentz & firefox-lorentz have all been resolved. We have talos turned on now.  I believe this branch is really really on - closing.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 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.