358845 - mZ test bogus for Firefox

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Boris Zbarsky [:bzbarsky]]

For Firefox, the mZ test reports completely bogus numbers.  I poked about, and basically mZ reports the sum total of the sizes of things listed in <http://lxr.mozilla.org/seamonkey/source/embedding/config/basebrowser-unix> and <http://lxr.mozilla.org/seamonkey/source/embedding/config/basebrowser-mac-macho>.  I assume the problem is that in static builds most of that stuff doesn't exist?  Is there an equivalent?  Just measuring the size of firefox-bin seems wrong too.

Ideally, I would think that mZ would report the size of libxul and Z would also include various other binary components Firefox has.  But we're not building libxul yet, are we?

Also, I question how useful the Z number is given the number of JS components we have around... but I'm not sure what we _really_ want to be measuring here.

Comment 1

[Benjamin Smedberg]

Yeah, mZ in Firefox is silly. We should be taking Z numbers from XULRunner for "embedded codesize" purposes.

Comment 2

[Boris Zbarsky [:bzbarsky]]

OK.  Do we have any xulrunner tinderboxen?  And more importantly, could we put them somewhere where people would actually see the mZ numbers?

Ideally, we'd have all of our "currently usefully supported" tinderboxen visible at once...

Comment 3

[Benjamin Smedberg]

http://tinderbox.mozilla.org/showbuilds.cgi?tree=XULRunner

I'm not sure we want to put all the "currently supported" tinderboxen in one place (at least by default... we should certainly work towards tinderbox server improvements where you can mix-and-match trees)... the XR tboxen are not tier-1 at the present time: if they break, we don't close the tree.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> I'm not sure we want to put all the "currently supported" tinderboxen in one
> place

Sure.  But I think tinderboxen running important tests should be in one place.  Otherwise people don't see some of the tests.  We've had problems with this before.

> if they break, we don't close the tree.

I think that that policy should change if that's where mZ is running.

Comment 5

[(not currently active) Ted Mielczarek]

I'm not sure at all where this bug belongs.

Comment 6

[cmtalbert]

It seems to me that this is a question for the XULRunner (and failing that) the mobile folks as they are the people currently working on embedding.  If this measurement is still being used then we should assign it to build to get it on the mobile tinderbox (where it seems it would be useful).  But, if this measurement is no longer used, we ought to just WONTFIX this. That's my opinion.

Comment 7

[Boris Zbarsky [:bzbarsky]]

This shouldn't be wontfixed no matter what.  We need to either make the number mean something or stop cluttering up tinderbox with it if no one cares about it.

Comment 8

[[e-mail] (:bhearsum)]

Nobody from RelEng will be working on this soon.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Well, is there a better component for just removing the output of this test from the Firefox tinderbox?  It's just taking up time and space there.

Comment 10

[Phil Ringnalda (:philor)]

Attachment: Don't produce a pointless number

One of these days, I really need to get buildbot installed (we have instructions, surely?), so I don't keep attaching patches with

"""
Of course, I don't know beyond obviousness that this works, and I'm going to need help and handholding to get it landed, too.
"""

Comment 11

[[e-mail] (:bhearsum)]

Comment on attachment 353294 [details] [diff] [review]
Don't produce a pointless number

This should do it.

Apologies for not being able to get to it sooner.

Comment 12

[[e-mail] (:bhearsum)]

Comment on attachment 353294 [details] [diff] [review]
Don't produce a pointless number

Checking in factory.py;
/cvsroot/mozilla/tools/buildbotcustom/process/factory.py,v  <--  factory.py
new revision: 1.70; previous revision: 1.69
done

I updated the master with this, too, new builds should be free of the mZ number.

Comment 13

[Chris Cooper [:coop] (he/him)]

Moving closed Future bugs into Release Engineering in preparation for removing the Future component.