Closed
Bug 566679
Opened 15 years ago
Closed 14 years ago
[Tracking Bug] Create new release branch "mozilla-2.0"
Categories
(Release Engineering :: General, defect, P5)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: joduinn, Unassigned)
References
Details
(Whiteboard: [automation])
Attachments
(9 files, 5 obsolete files)
7.40 KB,
patch
|
anodelman
:
review+
lsblakk
:
checked-in+
|
Details | Diff | Splinter Review |
1009 bytes,
text/plain
|
Details | |
7.09 KB,
patch
|
catlee
:
review+
lsblakk
:
checked-in+
|
Details | Diff | Splinter Review |
9.20 KB,
patch
|
anodelman
:
review+
lsblakk
:
checked-in+
|
Details | Diff | Splinter Review |
1.00 KB,
text/plain
|
anodelman
:
feedback+
|
Details |
77.33 KB,
patch
|
nthomas
:
review+
lsblakk
:
checked-in+
|
Details | Diff | Splinter Review |
9.25 KB,
patch
|
nthomas
:
review+
lsblakk
:
checked-in+
|
Details | Diff | Splinter Review |
7.16 KB,
patch
|
anodelman
:
review+
lsblakk
:
checked-in+
|
Details | Diff | Splinter Review |
2.76 KB,
patch
|
mozilla
:
review+
lsblakk
:
checked-in+
|
Details | Diff | Splinter Review |
In advance of FF4beta1, we need to create new branch and setup infrastructure for it. This bug is to track setup of tinderbox pages, TBPL, initial builds with updates, etc, etc.
Note: this branch will be *CLOSED* and contain experimental-only builds, as we test infrastructure setup. Sometime (approx mid-June?) beltzner will ask us to reset this repo from mozilla-central, and to then open the new branch to limited checkins. Until that point, this branch is to be ignored by everyone outside of RelEng.
Reporter | ||
Comment 1•15 years ago
|
||
The new repo should live in "releases/mozilla-1.9.3", beside repos for the other existing supported releases.
Priority: -- → P5
Updated•15 years ago
|
Whiteboard: [automation]
Updated•15 years ago
|
Assignee: nobody → lsblakk
I think you should clone it without store before http://hg.mozilla.org/mozilla-central/rev/6fa9e4164629 for fast cloning.
Comment 3•15 years ago
|
||
(In reply to comment #2)
> I think you should clone it without store before
> http://hg.mozilla.org/mozilla-central/rev/6fa9e4164629 for fast cloning.
I don't think that's possible with Mercurial.
Updated•15 years ago
|
Summary: Create new project branch "mozilla-1.9.3" → Create new release branch "mozilla-1.9.3"
Updated•15 years ago
|
Summary: Create new release branch "mozilla-1.9.3" → [Tracking Bug] Create new release branch "mozilla-1.9.3"
Updated•15 years ago
|
Depends on: bump-to-2.1
Comment 4•15 years ago
|
||
Attachment #450244 -
Flags: review?(anodelman)
Comment 5•15 years ago
|
||
Comment 6•15 years ago
|
||
Attachment #450246 -
Flags: review?(anodelman)
Updated•15 years ago
|
Attachment #450245 -
Attachment mime type: application/octet-stream → text/plain
Updated•15 years ago
|
Attachment #450244 -
Flags: review?(anodelman) → review+
Updated•15 years ago
|
Attachment #450246 -
Flags: review?(anodelman) → review+
Comment 7•15 years ago
|
||
Comment on attachment 450245 [details]
graph server insert statements for mozilla-1.9.3 branch
Graph server insert statement run on graphs-stage.
mysql> insert into branches values (NULL,"Firefox4.0");
Query OK, 1 row affected (0.01 sec)
mysql> insert into machines values (NULL,6,0,NULL,"Linux_mozilla-1.9.3",1,unix_timestamp());
Query OK, 1 row affected (0.00 sec)
mysql> insert into machines values (NULL,6,0,NULL,"Linux_mozilla-1.9.3_leak_test",1,unix_timestamp());
Query OK, 1 row affected (0.00 sec)
mysql> insert into machines values (NULL,7,0,NULL,"OS_X_10.5.2_mozilla-1.9.3",1,unix_timestamp());
Query OK, 1 row affected (0.01 sec)
mysql> insert into machines values (NULL,7,0,NULL,"OS_X_10.5.2_mozilla-1.9.3_leak_test",1,unix_timestamp());
Query OK, 1 row affected (0.00 sec)
mysql> insert into machines values (NULL,8,0,NULL,"WINNT_5.2_mozilla-1.9.3",1,unix_timestamp());
Query OK, 1 row affected (0.00 sec)
mysql> insert into machines values (NULL,8,0,NULL,"WINNT_5.2_mozilla-1.9.3_leak_test",1,unix_timestamp());
Query OK, 1 row affected (0.01 sec)
mysql> insert into machines values (NULL,17,0,NULL,"OS_X_10.6.2_mozilla-1.9.3",1,unix_timestamp());
Query OK, 1 row affected (0.00 sec)
mysql> insert into machines values (NULL,17,0,NULL,"OS_X_10.6.2_mozilla-1.9.3_leak_test",1,unix_timestamp());
Query OK, 1 row affected (0.00 sec)
mysql> insert into machines values (NULL,18,0,NULL,"Linux_x86-64_mozilla-1.9.3",1,unix_timestamp());
Query OK, 1 row affected (0.00 sec)
mysql> insert into machines values (NULL,18,0,NULL,"Linux_x86-64_mozilla-1.9.3_leak_test",1,unix_timestamp());
Query OK, 1 row affected (0.01 sec)
Comment 8•15 years ago
|
||
I just remembered that bsmedberg mentioned that we might be bumping the gecko version all the way to 2.0.0. If that happens, we should consider branching to mozilla-2.0.0 instead. (Newsgroup thread is here: http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/e0da78450d4effbc#)
Comment 9•15 years ago
|
||
Attachment #451696 -
Flags: review?(catlee)
Comment 10•15 years ago
|
||
Attachment #451697 -
Flags: review?(catlee)
Comment 11•15 years ago
|
||
and now with an Active branch setting!
Attachment #451696 -
Attachment is obsolete: true
Attachment #451716 -
Flags: review?(catlee)
Attachment #451696 -
Flags: review?(catlee)
Comment 12•15 years ago
|
||
Comment on attachment 450244 [details] [diff] [review]
data.sql patch for adding 1.9.3 branch
http://hg.mozilla.org/graphs/rev/adec4d554c55
Attachment #450244 -
Flags: checked-in+
Comment 13•15 years ago
|
||
Comment on attachment 451716 [details] [diff] [review]
adds mozilla-1.9.3 to buildbot-configs/mozilla
>+# L10n configuration
>+BRANCHES['mozilla-1.9.3']['enable_l10n'] = True
>+BRANCHES['mozilla-1.9.3']['enable_l10n_onchange'] = True
>+BRANCHES['mozilla-1.9.3']['l10nNightlyUpdate'] = True
>+BRANCHES['mozilla-1.9.3']['l10n_platforms'] = ['linux','win32','macosx']
>+BRANCHES['mozilla-1.9.3']['l10nDatedDirs'] = True
>+BRANCHES['mozilla-1.9.3']['l10n_tree'] = 'fx37x'
Is l10n_tree correct?
Attachment #451716 -
Flags: review?(catlee) → review+
Comment 14•15 years ago
|
||
Comment on attachment 451697 [details] [diff] [review]
mozilla-1.9.3 mozconfigs for staging and production default branch of buildbot-configs
Probably going to have to change CC/CXX on linux soon, but we'll stick with this for now.
Attachment #451697 -
Flags: review?(catlee) → review+
Comment 15•15 years ago
|
||
we should make the l10n tree fx40x, I'll migrate the dashboard over to that soon, too.
Comment 16•15 years ago
|
||
Comment on attachment 450246 [details] [diff] [review]
adds mozilla-1.9.3 to talos-r3 and talos-staging-pool
http://hg.mozilla.org/build/buildbot-configs/rev/a4186552afb6
Attachment #450246 -
Flags: checked-in+
Comment 17•15 years ago
|
||
Comment on attachment 451697 [details] [diff] [review]
mozilla-1.9.3 mozconfigs for staging and production default branch of buildbot-configs
http://hg.mozilla.org/build/buildbot-configs/rev/153e1981543b
Attachment #451697 -
Flags: checked-in+
Comment 18•15 years ago
|
||
Comment on attachment 451716 [details] [diff] [review]
adds mozilla-1.9.3 to buildbot-configs/mozilla
http://hg.mozilla.org/build/buildbot-configs/rev/a60e74ea6fb8
Attachment #451716 -
Flags: checked-in+
Comment 19•15 years ago
|
||
Lukas, I think you need to touch an empty nightly mar file for all locales so that the l10n nightlies on 1.9.3 get off the ground.
Comment 20•15 years ago
|
||
(In reply to comment #19)
> Lukas, I think you need to touch an empty nightly mar file for all locales so
> that the l10n nightlies on 1.9.3 get off the ground.
I just took care of this. For reference, I ran the following:
cd /home/ftp/pub/firefox/nightly/latest-mozilla-1.9.3-l10n
for i in `ls -1 ../latest-mozilla-central-l10n/*.mar`; do touch `basename $i`; done
Comment 21•15 years ago
|
||
(In reply to comment #20)
> for i in `ls -1 ../latest-mozilla-central-l10n/*.mar`; do touch `basename $i`;
> done
Scratch that. I've actually copied over the most recent complete mars from m-c instead. The mar creation process expects to be able to get a build id out of the mar, so this way it will actually work.
Reporter | ||
Comment 22•15 years ago
|
||
lsblakk:
Sorry to do this, but after some further discussions with shaver, looks like we now want this to be called "mozilla-2.0". (note: 2-digit, not 3).
No-one has landed anything in the mozilla-1.9.3 repo, so its ok to just blow it away, and create a new "releases/mozilla-2.0" repo.
Summary: [Tracking Bug] Create new release branch "mozilla-1.9.3" → [Tracking Bug] Create new release branch "mozilla-2.0"
Comment 23•15 years ago
|
||
please run this on staging graphserver
Attachment #452749 -
Flags: feedback?(anodelman)
Comment 24•15 years ago
|
||
Attachment #452756 -
Flags: review?(anodelman)
Comment 25•15 years ago
|
||
Comment on attachment 452749 [details]
sql replace statements for 1.9.3 -> 2.0
Don't want the 'select' in here. Double check with http://dev.mysql.com/doc/refman/5.0/en/replace.html
Attachment #452749 -
Flags: feedback?(anodelman) → feedback-
Updated•15 years ago
|
Attachment #452756 -
Flags: review?(anodelman) → review+
Comment 26•15 years ago
|
||
changed sql to mysql syntax.
Attachment #452749 -
Attachment is obsolete: true
Attachment #452792 -
Flags: feedback?
Comment 27•15 years ago
|
||
using update instead of replace
Attachment #452792 -
Attachment is obsolete: true
Attachment #452796 -
Flags: feedback?(anodelman)
Attachment #452792 -
Flags: feedback?
Comment 28•15 years ago
|
||
Comment on attachment 452796 [details]
sql replace statements for 1.9.3 -> 2.0
Applied to graphs-stage.
Query OK, 1 row affected (0.02 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> update machines set name= "Linux_mozilla-2.0_leak_test" where name = "Linux_mozilla-1.9.3_leak_test";
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> update machines set name= "OS_X_10.5.2_mozilla-2.0" where name = "OS_X_10.5.2_mozilla-1.9.3";
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> update machines set name = "OS_X_10.5.2_mozilla-2.0_leak_test" where name = "OS_X_10.5.2_mozilla-1.9.3_leak_test";
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> update machines set name = "WINNT_5.2_mozilla-2.0" where name = "WINNT_5.2_mozilla-1.9.3";
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> update machines set name = "WINNT_5.2_mozilla-2.0_leak_test" where name = "WINNT_5.2_mozilla-1.9.3_leak_test";
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> update machines set name = "OS_X_10.6.2_mozilla-2.0" where name = "WINNT_5.2_mozilla-1.9.3_leak_test";
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 0
mysql> update machines set name = "OS_X_10.6.2_mozilla-2.0_leak_test" where name = "OS_X_10.6.2_mozilla-1.9.3_leak_test";
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> update machines set name = "Linux_x86-64_mozilla-2.0" where name = "Linux_x86-64_mozilla-1.9.3";
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> update machines set name = "Linux_x86-64_mozilla-2.0_leak_test" where name = "Linux_x86-64_mozilla-1.9.3_leak_test";
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
Attachment #452796 -
Flags: feedback?(anodelman) → feedback+
Comment 29•15 years ago
|
||
Comment on attachment 452756 [details] [diff] [review]
renaming 1.9.3 to 2.0 in data.sql
http://hg.mozilla.org/graphs/rev/ec7ac12d0c76
Attachment #452756 -
Flags: checked-in+
Comment 30•15 years ago
|
||
Attachment #452877 -
Flags: review?(nrthomas)
Comment 31•15 years ago
|
||
Attachment #451697 -
Attachment is obsolete: true
Attachment #452878 -
Flags: review?(nrthomas)
Comment 32•15 years ago
|
||
had to backout the 1.9.3, adding back now as mozilla-2.0
Attachment #450246 -
Attachment is obsolete: true
Attachment #452884 -
Flags: review?(anodelman)
Comment 33•15 years ago
|
||
Comment on attachment 452877 [details] [diff] [review]
updates mozilla-1.9.3 mozconfigs -> mozilla-2.0
This looks fine. Next time use hg rename, and you'll get much easier to read diffs, eg:
diff --git a/mozilla2/linux/mozilla-1.9.3/codecoverage/mozconfig b/mozilla2/linux/mozilla-2.0/codecoverage/mozconfig
rename from mozilla2/linux/mozilla-1.9.3/codecoverage/mozconfig
rename to mozilla2/linux/mozilla-2.0/codecoverage/mozconfig
Attachment #452877 -
Flags: review?(nrthomas) → review+
Comment 34•15 years ago
|
||
Comment on attachment 452878 [details] [diff] [review]
updates mozilla/config.py for mozilla-1.9.3 -> mozilla-2.0
>diff --git a/mozilla/config.py b/mozilla/config.py
>+BRANCHES['mozilla-2.0']['platforms']['macosx-debug']['enable_unittests'] = False
>+BRANCHES['mozilla-2.0']['platforms']['macosx-debug']['packageTests'] = True
>+BRANCHES['mozilla-2.0']['platforms']['macosx']['enable_opt_unittests'] = False
>+BRANCHES['mozilla-2.0']['platforms']['macosx']['packageTests'] = True
>+BRANCHES['mozilla-2.0']['platforms']['linux-debug']['enable_unittests'] = False
>+BRANCHES['mozilla-2.0']['platforms']['linux-debug']['packageTests'] = True
>+BRANCHES['mozilla-2.0']['platforms']['linux']['enable_opt_unittests'] = False
>+BRANCHES['mozilla-2.0']['platforms']['linux']['packageTests'] = True
You should make this look like the mozilla-central equivalent, r+ with this fixed.
>diff --git a/mozilla/production_builder_master_pm01_localconfig.py b/mozilla/production_builder_master_pm01_localconfig.py
> ACTIVE_BRANCHES = ['places', 'addonsmgr', 'electrolysis', 'tracemonkey',
>- 'mozilla-1.9.1', 'mozilla-1.9.2', 'mozilla-central',
>+ 'mozilla-1.9.1', 'mozilla-1.9.2', 'mozilla-central', 'mozilla-2.0',
> 'maple', 'cedar', 'birch', 'jagermonkey']
It's a bit of a waste to turn on nightlies before the branch is in use, when bsmedberg says that could be this week, next week or the week after (depends how long the work to merge e10s and land retained-layers takes). Could we land this, make sure the nightly updates are being generated, then disable again ? That also limits the timeframe where we have Minefield builds coming from two branches.
Attachment #452878 -
Flags: review?(nrthomas) → review+
Updated•15 years ago
|
Attachment #452884 -
Flags: review?(anodelman) → review+
Comment 35•15 years ago
|
||
Comment on attachment 452884 [details] [diff] [review]
adds mozilla-2.0 to talos-r3 and talos-staging-pool
http://hg.mozilla.org/build/buildbot-configs/rev/9c29e7128488
Attachment #452884 -
Flags: checked-in+
Comment 36•15 years ago
|
||
Comment on attachment 452877 [details] [diff] [review]
updates mozilla-1.9.3 mozconfigs -> mozilla-2.0
http://hg.mozilla.org/build/buildbot-configs/rev/38a61ef14e88
Attachment #452877 -
Flags: checked-in+
Comment 37•15 years ago
|
||
Comment on attachment 452878 [details] [diff] [review]
updates mozilla/config.py for mozilla-1.9.3 -> mozilla-2.0
http://hg.mozilla.org/build/buildbot-configs/rev/ec937dfbe156
Attachment #452878 -
Flags: checked-in+
Comment 38•15 years ago
|
||
Lukas, are you happy to disable mozilla-2.0 in both builder masters _and_ scheduler until the branch is in use ? We're just filling up the ftp server with builds that are gonna be confusing, and using CPU unnecessarily.
Comment 39•15 years ago
|
||
Attachment #455472 -
Flags: review?(aki)
Updated•15 years ago
|
Attachment #455472 -
Flags: review?(aki) → review+
Comment 40•15 years ago
|
||
Comment on attachment 455472 [details] [diff] [review]
temporarily disable mozilla-2.0 from running in production
http://hg.mozilla.org/build/buildbot-configs/rev/a9866bdfbe92
Attachment #455472 -
Flags: checked-in+
Comment 41•15 years ago
|
||
(In reply to comment #40)
> (From update of attachment 455472 [details] [diff] [review])
> http://hg.mozilla.org/build/buildbot-configs/rev/a9866bdfbe92
This disabled polling for try! Fix:
http://hg.mozilla.org/build/buildbot-configs/rev/2d8e302e64f2
Comment 42•15 years ago
|
||
Adding two more, bug 597613 for the l10n dashboard, bug 597615 to make sure we have the right dirs on track for dep l10n builds, I think there will be some follow up fixes to make there.
Comment 43•15 years ago
|
||
FTR, bug 597616 for the l10n release repos is not FIXED, but INCOMPLETE to get off of ITs triage list until we're ready to do something to it.
Comment 44•14 years ago
|
||
most of the work here is done and since I'm not actively working on it I'm throwing it back in the pool until its day comes.
Assignee: lsblakk → nobody
Comment 45•14 years ago
|
||
Probably be a good idea to undisable polling, since someone changed the tree status to approval required, making someone think that it would be fine to push a test-fix patch to it, not knowing that it had been turned off for eight months and not turned back on.
Comment 47•14 years ago
|
||
I don't think that bug 597615 actually blocks this branch, it's good to have it connected here for posterity on tracking what needs doing for a new branch but I'm going to close this bug now since it's live and has releases being done off of it.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•12 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•