This is known. Bugs are on file, and the update will not be offered to PPC users.
I am gathering data on the number of PPC users we have, but the likely outcome is that we will not be supporting PPC for Firefox 4. More on that as I get the data.
We do have tests running on PPC, but nobody seems to be looking at them.
Today I tried Firefox 4.0 beta 4 build 3 on my old Powerbook and found it is totally broken. The URL bar doesn't response at all. I also tried m-c trunk, it is the same.
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.c...@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.
> This is known. Bugs are on file, and the update will not be offered to PPC users.
> I am gathering data on the number of PPC users we have, but the likely outcome is that we will not be supporting PPC for Firefox 4. More on that as I get the data.
> We do have tests running on PPC, but nobody seems to be looking at them.
> cheers, > mike
What could be the reasons to drop PPC support? (except no jit nor OOPP, IIRC)
Currently, these machines only track nightly builds for mozilla-central. This waterfall also has results for a pair of P3 machines running Linux and Windows XP.
John
On Aug 24, 2010, at 10:57 AM, Mounir Lamouri wrote:
> On 08/24/2010 01:43 PM, Mike Beltzner wrote: >> This is known. Bugs are on file, and the update will not be offered to PPC users.
>> I am gathering data on the number of PPC users we have, but the likely outcome is that we will not be supporting PPC for Firefox 4. More on that as I get the data.
>> We do have tests running on PPC, but nobody seems to be looking at them.
>> cheers, >> mike
> What could be the reasons to drop PPC support? (except no jit nor OOPP, > IIRC)
Mike Beltzner wrote: > This is known. Bugs are on file, and the update will not be offered to PPC users.
> I am gathering data on the number of PPC users we have, but the likely outcome is that we will not be supporting PPC for Firefox 4. More on that as I get the data.
> We do have tests running on PPC, but nobody seems to be looking at them.
> Today I tried Firefox 4.0 beta 4 build 3 on my old Powerbook and found it is totally broken. > The URL bar doesn't response at all. > I also tried m-c trunk, it is the same.
> 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.c...@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.
> On 2010-08-24, at 1:57 PM, Mounir Lamouri wrote:
>> What could be the reasons to drop PPC support? (except no jit nor OOPP, >> IIRC)
> Those would be the reasons.
These reasons look a bit alarming considering platforms that have been already been "tier 2" or lower. (I'd understand the decision to drop Mac PPC better if the stated reason were that it costs Mozilla too much to do in-house.)
Will Gecko 2.0 branch or Gecko going forward still support building a version that uses a JS interpreter without a JIT and in-process plug-ins? If yes, will such builds be eligible for "Firefox" branding?
(Neither Opera nor Safari on Mac PPC have a JIT or OOPP, so lacking those wouldn't make Firefox look particularly bad in comparison within the platform.)
> These reasons look a bit alarming considering platforms that have been already been "tier 2" or lower. (I'd understand the decision to drop Mac PPC better if the stated reason were that it costs Mozilla too much to do in-house.)
People keep talking about "tier 2" platforms. Where are those defined? What is the implication? This feels like something I should know, and perhaps I've missed a memo or convention somewhere. As far as I know, we have a list of supported operating systems and hardware, and then we have source code which can be maintained by anyone in the community to keep things working. Is that the distinction?
The reason is that we believe that Firefox should be fast, responsive and secure. We cannot deliver that on PPC anymore since we don't have support for the JIT on PPC, nor do we have support for OOPP. Nobody has come forward to help us with that work, and as you mention, the Mozilla Corporation is unwilling to bear the cost of hiring and supporting people to work solely on that platform.
> Will Gecko 2.0 branch or Gecko going forward still support building a version that uses a JS interpreter without a JIT and in-process plug-ins? If yes, will such builds be eligible for "Firefox" branding?
I can't really comment without data, but if there's no cost to disabling the JIT or OOPP codepaths, I don't see why not. I suspect that we won't brand any of those builds as "Firefox" though, but that would be a discussion with whomever wishes to publish those builds, as usual.
> (Neither Opera nor Safari on Mac PPC have a JIT or OOPP, so lacking those wouldn't make Firefox look particularly bad in comparison within the platform.)
Our goal is not to shoot for parity. Our goal is to deliver a consistent Firefox experience across platforms.
This is actually an important distinction in our world:
Tier 1: if you break the tree, or cause a perf regression, you are responsible for immediate backout/fix. This is pretty much "the main Firefox tinderbox"
Tier 2: We try to keep these platforms building, so hackers are expected to help get things building again, but we don't require immediate backouts. The mobile platforms (Android and Maemo) are somewhere inbetween tier 1 and tier 2 right now. We typically don't block releases on tier-2 platforms.
I think the current list of tier 1/2 platforms should be revised to reflect reality, and I'll post shortly with that proposal.
Tier 3: Platforms for which we accept patches.
>> Will Gecko 2.0 branch or Gecko going forward still support building a >> version that uses a JS interpreter without a JIT and in-process >> plug-ins? If yes, will such builds be eligible for "Firefox" branding?
> I can't really comment without data, but if there's no cost to disabling > the JIT or OOPP codepaths, I don't see why not. I suspect that we won't > brand any of those builds as "Firefox" though, but that would be a > discussion with whomever wishes to publish those builds, as usual.
Apart from the branding, this is the critical point which is at issue, I think. The ability of our codebase to be ported to new architectures (processors, widget toolkits, and OSes) has been a historical strength, and has served us well even recently in the mobile space. Entirely apart from questions of branding, I think we should be willing to pay some price in order to keep a working interpreter.
We are currently maintaining an interpreted version of the regex JIT for PPC, and that could be used by pretty much any of the tier-2/tier-3 ports, but it's slower. With JaegerMonkey, it's not clear whether we are going to continue to support the old interpeter as well as the JIT version or not.
Assuming that we don't start out with a JIT for PPC, or sparc, or any of the other 10 processors that Debian currently produces builds for: would we accept a JIT implementation for all of these architectures? There's definitely a cost in doing so, in both the shared code and code searchability and maintainability.
> Apart from the branding, this is the critical point which is at issue, I think. The ability of our codebase to be ported to new architectures (processors, widget toolkits, and OSes) has been a historical strength, and has served us well even recently in the mobile space. Entirely apart from questions of branding, I think we should be willing to pay some price in order to keep a working interpreter.
Some price, yes, but we should balance the costs against an the potential opportunity space gained by maintaining portability for a given architecture. (ex: I think that the maintaining portability to an ARM architecture carries more opportunity than does maintaining PPC, and have some data to back that claim up.)
> Assuming that we don't start out with a JIT for PPC, or sparc, or any of the other 10 processors that Debian currently produces builds for: would we accept a JIT implementation for all of these architectures? There's definitely a cost in doing so, in both the shared code and code searchability and maintainability.
You'd have to ask the module owner, I suspect. My instinct is that the cost of review would be too high.
> > Apart from the branding, this is the critical point which is at issue, I think. The ability of our codebase to be ported to new architectures (processors, widget toolkits, and OSes) has been a historical strength, and has served us well even recently in the mobile space. Entirely apart from questions of branding, I think we should be willing to pay some price in order to keep a working interpreter.
> Some price, yes, but we should balance the costs against an the potential opportunity space gained by maintaining portability for a given architecture. (ex: I think that the maintaining portability to an ARM architecture carries more opportunity than does maintaining PPC, and have some data to back that claim up.)
> > Assuming that we don't start out with a JIT for PPC, or sparc, or any of the other 10 processors that Debian currently produces builds for: would we accept a JIT implementation for all of these architectures? There's definitely a cost in doing so, in both the shared code and code searchability and maintainability.
> You'd have to ask the module owner, I suspect. My instinct is that the cost of review would be too high.
