Closed Bug 434844 Opened 12 years ago Closed 12 years ago

No Mozilla2 tinderboxes are running the codesize test

Categories

(Release Engineering :: General, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dbaron, Assigned: bhearsum)

References

Details

Attachments

(4 files, 3 obsolete files)

After the discussion in bug 434085 I noticed that no tinderboxes on http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla2 are running the Codesize (Z:) test.  This is run on the build machines on the Firefox tinderbox:
Linux fx-linux-tbox Dep Nightly
MacOSX Darwin 8.8.4 bm-xserve08 Dep Universal Nightly

(I'm not sure if we ever had it running on Windows.)
It hasn't run on windows since we switched from VC6, I think, since the scripts were never updated to work with VC8 changes.
Do we actually care about this test? Does anyone look at the results? Windows never getting fixed seems to hint that people don't.
Yes, we do care, and it has pointed out major regressions (such as the NSS debacle). It's not so important to get it on all platforms.
FWIW, VC stopped supporting -MAPINFO:LINES in VC8, which is probably why codesighs doesn't work there. Not having any idea how codesighs actually works, I would wager that we could make it read breakpad symbol files for the info it needs, but that's probably a lot of effort just to get Windows support back.
(In reply to comment #2)
> Do we actually care about this test? Does anyone look at the results? Windows
> never getting fixed seems to hint that people don't.
Good question, bhearsum.

(In reply to comment #3)
> Yes, we do care, and it has pointed out major regressions (such as the NSS
> debacle). It's not so important to get it on all platforms.
Which platforms *are* important? From bhearsum's observations, is it fair to say win32 is not important?


Triaging this to P3/Future, until these questions and comment#4 are resolved. If you feel this should be higher priority, or should block opening the tree, please comment here.
Component: Release Engineering → Release Engineering: Future
Priority: -- → P3
Yes, we do look at the results, but they're generally (although not always) pretty consistent across platforms.  It's important to have it running on at least one platform.  Note that this bug is currently marked as blocking opening mozilla-central.
-> bhearsum per today's meeting
Assignee: nobody → bhearsum
We use 'build' as the srcdir for hg builds. This patch simply fixes basesummary.*.bash to work with srcdirs that aren't named 'mozilla'.

I have no idea who can review this. dbaron? bsmedberg?
Attachment #322767 - Attachment is obsolete: true
Comment on attachment 322768 [details] [diff] [review]
[checked in] forgot to re-diff

r=me for mozilla-central
Attachment #322768 - Flags: review+
Comment on attachment 322768 [details] [diff] [review]
[checked in] forgot to re-diff

landed in changeset:   15147:35749543c3d1
Attachment #322768 - Attachment description: forgot to re-diff → [checked in] forgot to re-diff
Status: NEW → ASSIGNED
Raising priority(In reply to comment #3)
> Yes, we do care, and it has pointed out major regressions (such as the NSS
> debacle). It's not so important to get it on all platforms.

(In reply to comment #7)
> -> bhearsum per today's meeting

Raising priority, based on meeting. Getting this running on any *one* o.s. will be enough to unblock opening mozilla-central. Ben is working on linux, might get mac for free. Win32 is known to not work, see comment#2, comment#4.

Note: no-one here knows how this codesize test actually works, so Ben is learning this as he figures his way through. Any help very very welcome.
Status: ASSIGNED → NEW
Component: Release Engineering: Future → Release Engineering
Priority: P3 → P1
Forgot to check this file for the same thing.
Attachment #322825 - Flags: review?(benjamin)
Attachment #322825 - Flags: review?(benjamin) → review+
Comment on attachment 322825 [details] [diff] [review]
[checked in] same thing for autosummary.unix.bash

landed in changeset:   15148:d87f575aac59
Attachment #322825 - Attachment description: same thing for autosummary.unix.bash → [checked in] same thing for autosummary.unix.bash
Attachment #322941 - Flags: review?(ccooper)
Attachment #322940 - Flags: review?(ccooper) → review+
Attachment #322941 - Flags: review?(ccooper) → review+
So, Ben, just to be clear, do the two patches above actually fix this bug for linux and mac?
They should, yes.

That reminds me though, I need to see what this does to the Windows builds.
Comment on attachment 322940 [details] [diff] [review]
[checked in] buildstep to run codesighs + parse the output

Checking in test.py;
/cvsroot/mozilla/tools/buildbotcustom/steps/test.py,v  <--  test.py
new revision: 1.3; previous revision: 1.2
done
Attachment #322940 - Attachment description: buildstep to run codesighs + parse the output → [checked in] buildstep to run codesighs + parse the output
I prelanded the macosx mozconfig change so I can get this going this morning.
Landed in changeset:   93:2b599aabd08a
Status: NEW → ASSIGNED
Landed the codesighs patches on actionmonkey in changeset:   15009:d0336075d42a.
Comment on attachment 322971 [details] [diff] [review]
disable codesighs on win32, add --enable-codesighs to mac mozconfig

I forgot at least one thing in this patch, I'll repost soon.
Attachment #322971 - Attachment is obsolete: true
Attachment #322971 - Flags: review?(ccooper)
Attachment #323082 - Flags: review?(ccooper) → review+
Comment on attachment 323082 [details] [diff] [review]
[checked in] enable codesighs on production master, proper

landed in changeset:   95:b17ba2381389
Attachment #323082 - Attachment description: enable codesighs on production master, proper → [checked in] enable codesighs on production master, proper
Attachment #322941 - Attachment is obsolete: true
And we are done here.
Status: ASSIGNED → RESOLVED
Closed: 12 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.