Closed
Bug 486513
Opened 16 years ago
Closed 16 years ago
xulrunner 3.5/3.6 builds report to the Firefox3.5/Firefox tinderboxes
Categories
(Release Engineering :: General, defect, P2)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bhearsum, Assigned: nthomas)
Details
Attachments
(1 file)
|
3.73 KB,
patch
|
nthomas
:
review+
nthomas
:
checked-in+
|
Details | Diff | Splinter Review |
...and they really shouldn't. Historically, we've had a different tinderbox for XULRunner. Given that we're only doing nightly builds, I don't know if we *need* to report them somewhere, but it would be nice. We could probably just use the existing XULRunner tinderbox without moving the old/existing builds off of it.
Comment 1•16 years ago
|
||
Looks like this is because they're placed into nightlyBuilders.
We could create a xulrunnerNightlyBuilders, or convert nightlyBuilders into a dictionary, or add a function that adds the builder to the appropriate place(s), with defaults that can be overridden (e.g. tinderboxTree). It would seem that xulrunnerNightlyBuilders would be the solution closest to what we have now.
Comment 2•16 years ago
|
||
I don't know...I think they _should_ be reporting to the same trees as Firefox, since they share the same code. But I don't feel super strongly about that...so -0 on this.
Comment 3•16 years ago
|
||
future? wontfix? xulrunnerNightlyBuilders?
| Reporter | ||
Comment 4•16 years ago
|
||
If nobody is going to take it, future, I guess. Definitely not WONTFIX IMHO.
Comment 5•16 years ago
|
||
This patch should send production xulrunner builds to the XULRunner tree, and staging builds to MozillaTest.
Comment 6•16 years ago
|
||
Dunno if you wanted review on that, but it looks good to me. The treename could go in config.py but it looks like we have tree names in master.cfg elsewhere as well.
| Assignee | ||
Comment 7•16 years ago
|
||
I think we should move them to the XULRunner tree. There was a bustage in javaxpcom in the last 24 hours which was caught by having builds (great!), but that code's not built by Firefox so is effectively spurious red against mozilla-central tree (bad!).
| Assignee | ||
Comment 8•16 years ago
|
||
(In reply to comment #7)
Filed bug 487960 on that bustage.
| Assignee | ||
Comment 9•16 years ago
|
||
XULRunner builds are hidden on the Firefox tree for now.
Comment 10•16 years ago
|
||
Would landing this patch allow us to close this bug as FIXED? Or is there anything else to do here?
OS: Mac OS X → All
Hardware: x86 → All
| Assignee | ||
Comment 11•16 years ago
|
||
I'll get this landed today.
Assignee: nobody → nthomas
Priority: -- → P2
| Assignee | ||
Comment 12•16 years ago
|
||
Comment on attachment 371862 [details] [diff] [review]
Send xulrunner logs to XULRunner tinderbox
committed changeset 1091:314fe74857fb
Attachment #371862 -
Flags: review+
Attachment #371862 -
Flags: checked‑in+
Attachment #371862 -
Flags: checked‑in+ review+
| Assignee | ||
Comment 13•16 years ago
|
||
Aki did a reconfig on production-master:moz2-master at 15:05 PDT for this. I've started a Linux mozilla-1.9.1 build off and it has reported to the XULRunner tree. Scheduler looks good on the buildbot waterfall too. --> FIXED.
Thanks for the patch Chris!
| Assignee | ||
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
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
•