Closed Bug 639980 Opened 11 years ago Closed 11 years ago

set up releases/mobile-2.0 branch

Categories

(Release Engineering :: General, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: aki, Assigned: aki)

References

Details

Attachments

(8 files, 9 obsolete files)

1.16 KB, patch
jhford
: review+
Details | Diff | Splinter Review
1.94 KB, patch
aki
: review+
Details | Diff | Splinter Review
11.62 KB, patch
lsblakk
: review+
Details | Diff | Splinter Review
3.21 KB, patch
bhearsum
: review+
Details | Diff | Splinter Review
24.58 KB, patch
lsblakk
: review+
Details | Diff | Splinter Review
2.30 KB, patch
bhearsum
: review+
Details | Diff | Splinter Review
3.19 KB, patch
jhford
: review+
Details | Diff | Splinter Review
861 bytes, patch
Details | Diff | Splinter Review
- building against releases/mozilla-2.1
- reporting to Mobile2.0 tinderbox page

Don't forget: graphs, tbpl, n900s, tegras, probably other things I'm currently forgetting.
Attached patch add mobile-2.0 branch to graphs (obsolete) — Splinter Review
I wasn't sure if I should call this mobile-2.0 (mobile branch name) or mobile-2.1 (mozilla branch name with s,mozilla,mobile,).

mobile-2.0 makes more sense in a way, but mobile-1.9.2 kind of assumes mobile-2.1.

I'm going to stop thinking about this and work on the other patches.
Attached patch aus: s,mozilla-2.0,mozilla-2.1,g (obsolete) — Splinter Review
This means I need to update my configs patch to include mobile-2.0 mozconfigs and point to them.
Attachment #517922 - Flags: review?(nrthomas)
Attachment #517918 - Attachment is obsolete: true
Attachment #517880 - Flags: review?(jhford)
Attachment #517880 - Flags: review?(jhford)
Attachment #517880 - Attachment is obsolete: true
Attachment #517932 - Flags: review?(jhford)
Attachment #517865 - Attachment is obsolete: true
Attachment #517933 - Flags: review?(jhford)
Comment on attachment 517922 [details] [diff] [review]
aus: s,mozilla-2.0,mozilla-2.1,g

Looks fine when I turn it into a context diff ;-) Let me know if you want help landing, tagging, getting it pushed.
Attachment #517922 - Flags: review?(nrthomas) → review+
(In reply to comment #7)
> Comment on attachment 517922 [details] [diff] [review]
> aus: s,mozilla-2.0,mozilla-2.1,g
> 
> Looks fine when I turn it into a context diff ;-) Let me know if you want help
> landing, tagging, getting it pushed.

Oops, I *used* to always to cvs diff -U9 til .hgrc trained me otherwise.
And thanks!
Attaching context diff; carrying forward r+
Attachment #517922 - Attachment is obsolete: true
Attachment #517936 - Flags: review+
Attachment #517936 - Attachment description: same, but with diff -U9 → aus patch: same, but with diff -U9
Comment on attachment 517936 [details] [diff] [review]
aus patch: same, but with diff -U9

Checking in xml/inc/config-dist.php;
/cvsroot/mozilla/webtools/aus/xml/inc/config-dist.php,v  <--  config-dist.php
new revision: 1.119; previous revision: 1.118
done

This will most likely go live when bug 640044 does.
Attachment #517936 - Flags: checked-in+
* Adds mozilla-2.1 branch to mozilla/config.py and mozilla-tests/config.py, currently with only mobile platforms enabled.
 * However, I haven't disabled the desktop tests yet because I imagine we'll want some coverage at some point.
* This assumes mozilla-2.0 will be a Firefox 4.0 only branch, and mozilla-2.1 will be a Fennec 4.0 only branch. Therefore *tinderbox_tree is set to Firefox4.0 and Mobile2.0, respectively.
* I didn't find maemo5-gtk or maemo5-qt's pf-specific l10n_repo_path used anywhere.  Removed.
* Where applicable (android, *-i686) I hg cp'ed the mozconfig directory and edited. On other platforms I simply ln -s'ed and hg add'ed.
 * Specified Android mobile-2.0 update channel to nightly-mozilla-2.1
* Currently commented out of production ACTIVE_BRANCHES like mozilla-2.0.
* l10n dir/repo set to l10n-mozilla-2.0
Depends on: 640067
Comment on attachment 517947 [details] [diff] [review]
mozilla-2.1 / mobile-2.0 configs, with mozconfigs + tests

Currently running staging builds; I'll obsolete the patch later tonight if anything unexpected comes up.
Attachment #517947 - Flags: review?(bhearsum)
Working on a green staging run =P
Attachment #517947 - Attachment is obsolete: true
Attachment #517947 - Flags: review?(bhearsum)
Attachment #518011 - Flags: review?(bhearsum)
Ugh, there's a mobile-browser hidden somewhere in the win32 repacks.
Tracking down later.
Attached patch configs v4: add mobile_repo_path (obsolete) — Splinter Review
Looks like I need a buildbotcustom + build/tools patch for mobile nightly l10n.
Will get good staging runs before asking for r? again =P
Attachment #518011 - Attachment is obsolete: true
Attachment #518011 - Flags: review?(bhearsum)
Repacks are still failing without a clear error message, after manually clobbering the build dir.

http://staging-master.build.mozilla.org:8010/builders/WINNT%205.2%20Mobile%20Desktop%20mozilla-2.1%20l10n%20nightly%201%2F6/builds/5/steps/run_script/logs/stdio

I'm probably going to proceed with a followup bug.
Attachment #518129 - Attachment is obsolete: true
Attachment #518181 - Flags: review?(bhearsum)
Attachment #517991 - Flags: review?(lsblakk)
Comment on attachment 518141 [details] [diff] [review]
configs v5: get rid of errant trailing ,

Ben: tag since you're the one that knows the mobile-l10n stuff.
However, let me know if you need me to switch this to someone else (or I will if you end your day w/out addressing these).
Attachment #518141 - Flags: review?(bhearsum)
Attachment #518128 - Flags: review?(bhearsum)
Attachment #517991 - Flags: review?(lsblakk) → review+
Comment on attachment 517933 [details] [diff] [review]
graphs: now with 100% more mobile-2.0-qt

lgtm
Attachment #517933 - Flags: review?(jhford) → review+
Comment on attachment 518141 [details] [diff] [review]
configs v5: get rid of errant trailing ,

>     'mozilla-2.0': {
>         'tinderbox_tree': 'Firefox4.0',
>         'packaged_unittest_tinderbox_tree': 'Firefox4.0',
>     },
>+    'mozilla-2.0': {
>+        'tinderbox_tree': 'Mobile2.0',
>+        'mobile_tinderbox_tree': 'Mobile2.0',
>+        'packaged_unittest_tinderbox_tree': 'Mobile2.0',
>+    },
>     'tracemonkey': {

s/mozilla-2.0/mozilla-2.1

Other than that, looks good to me.
Attachment #518141 - Flags: review?(bhearsum) → review+
Attachment #517932 - Attachment is obsolete: true
Attachment #517932 - Flags: review?(jhford)
Attachment #518205 - Flags: review?(jhford)
Attachment #518205 - Flags: review?(jhford) → review+
Comment on attachment 518128 [details] [diff] [review]
buildbotcustom: fix mobile l10n branch

We should fix this (and the other l10n jobs, maybe) to use $mobileRepo-$mobileRepo as the branc hat some point. Doesn't need to be addressed here, though.
Attachment #518128 - Flags: review?(bhearsum) → review+
Attachment #518181 - Flags: review?(bhearsum) → review+
Attachment #518468 - Flags: review? → review?(bhearsum)
Comment on attachment 518468 [details] [diff] [review]
enable mozilla-2.0 and mozilla-2.1

Holding off on this until we get a concrete statement that we want this.
Attachment #518468 - Flags: review?(bhearsum)
I fountdI found out on IRC today that we're not going to be doing nightlies for
mozilla-2.0, apparently. I don't know whether this is Desktop only, or applies
to Mobile too. I don't know if applies in any way to mozilla-2.1.

We'll have to tweak enable_nightly, enable_mobile_nightly and l10nNightlyUpdate
flags appropriately once we find out.

cc'ing some people who may know the answer.
What we *do* know, in terms of desktop:

1) we do not want users to end up on the branch nightlies, if there are any. We want all the nightly users to stay on the mozilla-central train.
2) We have not yet decided whether to do any Firefox 4.x stability releases, other than chemspills. If we do these, they will be released directly to the beta channel.
3) In that case, nightlies would really only be useful for regression-range finding.
Reconfiged.
I'd prefer to kick off nightlies and dep builds to make sure this is all ship shape, but we will be able to deal with that if/when we want nightlies turned on, with a few days' lead time.
Status: NEW → RESOLVED
Closed: 11 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.