Then I thought it could be Bug 587612.
I'm sorry I didn't realize the break would be so big when I file the bug.
I pushed my patch to try sever.
Try server build works fine on my Powerbook.
Builds at: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/ginn...@sun.com-b157835cf45e
I don't know if we still want to support Mac/PPC.
Since we are doing universal binaries, I guess the answer might be yes.
If so, I think we should do some testings, maybe through Rossetta if we can't find PPC machines.
Thanks,
Ginn
"we will also not support PPC Mac for Firefox 4"
> Mozilla has previously shipped Firefox on Mac PPC without a JIT or without OOPP, so Firefox is not becoming slower on PPC in an absolute sense. What's considered "fast" is moving in the relative sense. It seems a bit odd to withdraw on performance grounds a product that's not getting slower in a absolute sense--when it's the frame of reference within the set of "all" platforms (as opposed to within the PPC platform itself) is that's changing *and* the only way for the users to follow the frame of reference is to replace their current still working hardware (that is, they can't get a JIT for PPC from anyone else, either).
I agree with everything you've said above. I think where we differ is how we define "Firefox 4". I believe that Firefox 4 should be relatively faster and superior to previous versions - so to be better than Firefox 3.6. Two of the significant mechanisms for performance improvement will not be available for PPC based computers, and so we are not planning on extending Firefox 4 support to those architectures.
Users will be able to continue to use Firefox 3.6 on PPC based computers, and benefit from our stability and security releases on that branch.
>> Our goal is not to shoot for parity. Our goal is to deliver a
>> consistent Firefox experience across platforms.
>
> That's why I asked about branding eligibility. If Mozilla's position for Mac PPC is that interpreter and in-process plug-ins aren't good enough to be "Firefox" when compared across platforms, does it follow that e.g. Fedora would have to brand their PPC build as non-Firefox while branding their x86 and x86_64 builds as Firefox? (Such a requirement would seem like something that would make the relationship of Mozilla and the distros worse again.)
I don't think that's really relevant to our discussion of whether or not we decide to ship Firefox 4 builds for PPC architectures, though. Do you?
cheers,
mike
Also note that non-JITed, just intepreted JS has become a lot faster in
recent versions and even has a significant win from 1.9.2 to 2.0 trees.
Robert Kaiser
When the foremost reason is that builds without JIT or OOPP aren't good enough to be "Firefox 4" from Mozilla for Mac PPC, yes, I think it's relevant to whether no JIT and/or no OOPP is good enough to be "Firefox 4" when shipped by someone else (most likely a Linux distro). If the foremost reason were that Mac PPC is too few users left for too much cost, then I wouldn't consider trademark licensing to others relevant to the decision for MoCo not to ship on Mac PPC.
I am not trying to argue for Mozilla Corporation shipping for Mac PPC even though I think it's unfortunate that Mac PPC gets dropped so late in the product cycle when the possibility of letting Mac PPC limp along for this major release is so close. I'm more interested in / concerned about how the reasoning behind dropping Mac PPC generalizes (or doesn't generalize?) into policy affecting non-MoCo builds (both in terms of what platforms the code can technically be built for and in terms of what gets trademark permission to be called "Firefox 4").
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
> I am not trying to argue for Mozilla Corporation shipping for Mac PPC even though I think it's unfortunate that Mac PPC gets dropped so late in the product cycle when the possibility of letting Mac PPC limp along for this major release is so close. I'm more interested in / concerned about how the reasoning behind dropping Mac PPC generalizes (or doesn't generalize?) into policy affecting non-MoCo builds (both in terms of what platforms the code can technically be built for and in terms of what gets trademark permission to be called "Firefox 4").
And I'm saying that's not really relevant to the conversation at hand, which is "do we do any testing on Mac/PPC, and should such problems block the release of Firefox 4."
What you'd like to talk about is an interesting topic; I don't think there's an automatic generalization there, or a crisp policy. I also don't really have time to engage in that broader topic at this time.
cheers,
mike
The short answer is yes.
Speaking from QA, we do test on Mac PPC for every release we support
PPC. For 4.0, this means testing PPC until support is officially
dropped. For 3.0.x, 3.5.x, and 3.6.x this means testing PPC until
these branches are end-of-lifed. Our test coverage for PPC typically
involves update verifications, verifying resolved bugs, and conducting
spotchecks for the most common browser functionality.
This testing policy will not change as long as we support releases.
As has been stated many times before, dropping of PPC support for 4.0
does not mean dropping of support for all branches of Firefox.
Mozilla will continue to support PPC on 3.0, 3.5, and 3.6 through
security releases, and QA will continue to test them.
These tests stopped working on the August 14th nightlies.
This is the waterfall page for the first set of tests that flat out failed:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=GeriatricMachines&maxdate=1281804871&legend=0&norules=1
And the last ones that did work:
-http://tinderbox.mozilla.org/showbuilds.cgi?tree=GeriatricMachines&maxdate=1281718471&legend=0&norules=1
This testing was announced in a blog post [1] that I believe showed up on planet.
John Ford
[1] http://blog.johnford.info/unittests-on-ppc-and-non-sse2-machines/
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning