Closed Bug 358845 Opened 16 years ago Closed 14 years ago
Z test bogus for Firefox
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.
Yeah, mZ in Firefox is silly. We should be taking Z numbers from XULRunner for "embedded codesize" purposes.
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...
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.
> 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.
Assignee: build → nobody
Component: Tinderbox Configuration → Testing
Product: mozilla.org → Core
QA Contact: ccooper → testing
Version: other → Trunk
I'm not sure at all where this bug belongs.
Component: Testing → Release Engineering
Product: Core → mozilla.org
QA Contact: testing → release
Version: Trunk → other
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.
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.
Nobody from RelEng will be working on this soon.
Component: Release Engineering → Release Engineering: Future
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.
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. """
Attachment #353294 - Flags: review?(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.
Attachment #353294 - Flags: review?(bhearsum) → review+
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.
Attachment #353294 - Flags: checked‑in+
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Moving closed Future bugs into Release Engineering in preparation for removing the Future component.
Component: Release Engineering: Future → Release Engineering
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.