Closed
Bug 294150
Opened 20 years ago
Closed 20 years ago
50% Ts regression since landing of bug 293461
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
FIXED
Firefox1.5
People
(Reporter: stevee, Assigned: benjamin)
References
Details
(Keywords: regression)
Attachments
(1 file)
4.91 KB,
patch
|
darin.moz
:
review+
shaver
:
approval-aviary1.1a1+
|
Details | Diff | Splinter Review |
Beast startup times according to:
-
http://build-graphs.mozilla.org/graph/query.cgi?tbox=beast&testname=startup&autoscale=0&size=1.5&days=5&units=<ype=&points=&avg=1
show a 50% increase in Ts. Judging by
-
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox&hours=24&maxdate=1115939632&legend=0
it appears the cause of this regression was the landing of bug 293461
cc: Benjamin
Updated•20 years ago
|
Flags: blocking-aviary1.1?
Comment 1•20 years ago
|
||
Ts went up by more like 60-70% on beast (Win) and imola (Mac).
Benjamin, can you back this out or fix ASAP? I'll back this out tonight if no
action has been taken, since we're possibly spinning 1.1a1 Monday.
Flags: blocking1.8b2?
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Assignee | ||
Comment 2•20 years ago
|
||
Hold off and talk to me this (Monday) morning... I'm debugging this now.
Assignee: nobody → benjamin
Assignee | ||
Comment 3•20 years ago
|
||
This needs love for 1.1a, either the fix in bug 293548 or a backout of bug
293461... but a backout would be painful because other stuff has landed on top
of it.
Flags: blocking1.8b2? → blocking1.8b2+
Comment 4•20 years ago
|
||
Time is very short for 1.8b2/1.1a. If we're not gonna have a fairly safe fix
today, then let's back this out.
Comment 5•20 years ago
|
||
Asa: I'm planning on landing the patch for bug 293548, which will fix this bug.
Comment 6•20 years ago
|
||
My patch for bug 293548 is in, so I think we can mark this bug fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 7•20 years ago
|
||
reopening... beast Ts did not come down after the patch landed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 8•20 years ago
|
||
Attachment #183830 -
Flags: review?(darin)
Comment 9•20 years ago
|
||
Ben mentioned that you should verify that the EM cleans up its datasource when
the "extensions" folder happens to have been deleted. For example, just go and
manually delete that folder, and then verify that EM recovers from that
situation. I believe it should since we scan install locations at startup to
determine the actual items and then compare that against the known items to
determine what needs to be installed, removed, or updated.
Updated•20 years ago
|
Attachment #183830 -
Flags: review?(darin) → review+
Assignee | ||
Comment 10•20 years ago
|
||
Comment on attachment 183830 [details] [diff] [review]
Remove silly "isFunctioning" test that always fails on new -createProfile builds
Low-risk, high-reward.
Attachment #183830 -
Flags: approval-aviary1.1a1?
Comment 11•20 years ago
|
||
Comment on attachment 183830 [details] [diff] [review]
Remove silly "isFunctioning" test that always fails on new -createProfile builds
a=shaver.
Attachment #183830 -
Flags: approval-aviary1.1a1? → approval-aviary1.1a1+
Assignee | ||
Comment 12•20 years ago
|
||
Fixed on trunk for 1.1a1.
Severity: normal → major
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox1.1
Comment 13•20 years ago
|
||
*** Bug 294740 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•