Re: Do we do any testing on Mac/PPC? Possible blocker for Firefox 4.0 beta 4

[Mike Beltzner]

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

Ginn Chen <Ginn...@Sun.COM> wrote:

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...@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
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning

[Mounir Lamouri]

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)

--
Mounir

[John Ford]

We have unit test coverage on mozilla-central for PPC builds running on a G5 and G4. The results are posted to

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

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

[Mike Beltzner]

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.

cheers,
mike

[Phillip Jones]

add me to list of PPC machines I use two a Laptop and a Desktop.

--
Phillip M. Jones, C.E.T. "If it's Fixed, Don't Break it"
http://www.phillipmjones.net/ mailto:pjo...@kimbanet.com

[Mike Beltzner]

On 2010-08-24, at 2:13 PM, Phillip Jones wrote:

> add me to list of PPC machines I use two a Laptop and a Desktop.

We are not keeping a list.

cheers,
mike

[Ginn Chen]

It's sad to know we're dropping support for ppc.
But I'm glad to hear we're still on track.

Thanks,

Ginn

[Henri Sivonen]

On Aug 24, 2010, at 21:06, Mike Beltzner wrote:

> 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.)

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Mike Beltzner]

On 2010-08-25, at 3:17 AM, Henri Sivonen wrote:

> 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.

cheers,
mike

[Benjamin Smedberg]

On 8/25/10 8:45 AM, Mike Beltzner wrote:

> People keep talking about "tier 2" platforms. Where are those defined?

https://developer.mozilla.org/en/Supported_build_configurations

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.

--BDS

[Mike Beltzner]

On 2010-08-25, at 9:26 AM, Benjamin Smedberg wrote:

> On 8/25/10 8:45 AM, Mike Beltzner wrote:
>
>> People keep talking about "tier 2" platforms. Where are those defined?
>
> https://developer.mozilla.org/en/Supported_build_configurations

Thanks for that!

> 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.

cheers,
mike

[Yuhong Bao]

BTW, this thread has been turned into a news article:
http://news.cnet.com/8301-30685_3-20014666-264.html