Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Dropping Mac OS X 10.4 support in Gecko 1.9.3

153 views
Skip to first unread message

Josh Aas

unread,
Feb 5, 2010, 12:16:10 AM2/5/10
to
In September of 2009 we stopped supporting Mac OS X 10.4 ("Tiger") on
mozilla-central but we left much of the code required to support that
platform in the tree in case we wanted to reverse that decision. We
have come to a point where we need to make a final decision and either
restore 10.4 support or remove this (large) amount of 10.4 specific
code.

Here are usage numbers from 2010-01-25:

===========
Firefox 3.5
===========
10.6 (Darwin 10.x): 1,497,221 (26%)
10.5 (Darwin 9.x): 2,855,842 (50%)
10.4 (Darwin 8.x): 1,379,770 (24%)
All versions of Mac OS X: 5,732,833

===========
Firefox 3.6
===========
10.6 (Darwin 10.x): 186,825 (59%)
10.5 (Darwin 9.x): 91,478 (29%)
10.4 (Darwin 8.x): 35,960 (12%)
All versions of Mac OS X: 314,263

Mac OS X 10.4 was released in April of 2005 and a lot has changed
since then. We would like to take advantage of more modern
technologies on Mac OS X and 10.4 support has been a hindrance. Where
we can work around supporting 10.4, doing so consumes valuable time
and effort. Neither Chrome nor Safari has to deal with this.

The approximately 25% of our Mac OS X users still on 10.4 would
continue to be supported by Firefox 3.6 until that product reaches end
of service, which won't be until several months after the next major
version of Firefox is delivered (built on Gecko 1.9.3) later this
year. Past data shows that we do not lose appreciable market share
when we stop supporting a Mac OS X version. We are often one of the
last vendors to continue supporting older Mac OS X releases, and I
suspect that by the time this becomes an issue Apple may themselves
have stopped issuing security updates for Mac OS X 10.4.

Adding 10.4 support back to mozilla-central would mean switching back
to ATSUI from Core Text, switching back to gcc-4.0 from gcc-4.2, and
doing a bit of porting work for code that has been added to the tree
since we dropped support for 10.4. Other areas where 10.4 support
consumes our time, makes our code more complex or error-prone, and/or
limits our capabilities include complex text input (IME), out-of-
process plugins, printing, native menus, and Core Animation.
Furthermore, Apple's upcoming JavaPlugin2 will not support Mac OS X
10.4.

We are planning to make the decision to remove 10.4 support final and
remove the code from the tree. If you have any strong objections
please let us know now.

Jean-Marc Desperrier

unread,
Feb 5, 2010, 7:16:12 AM2/5/10
to
Josh Aas wrote:
> Furthermore, Apple's upcoming JavaPlugin2 will not support Mac OS X
> 10.4.

Since support for plugin1 has already been removed from trunk, this
means supporting 10.4 in 1.9.3 would *also* mean reintroducing it.

Phillip Jones

unread,
Feb 5, 2010, 11:17:56 AM2/5/10
to
Absolutely Not. I still have two PowerPC machine That use OSX.4.11. My
Laptop I could if I had the funds go to OSX.5. but it would make it
slower than the molasses It already is. As it stand now it impractical
for me update either machine due to lack of funds. Maybe in 2011 I can
upgrade my Laptop. But not this year . I am going to have to dip into my
savings to maintain a decent amount in my Checking this year. My Desktop
will have to wait even longer. Its a G4-500 and and even OSX.5.8 is not
recommended for it. So if support for 4.11 is removed then that means I
will have to go to something else such a iCab, Opera, or OmiWeb rather
than FF. (FireFox) and you don't need to loose users.

And I am not the only one. I just happen to be the only one to voice an
opinion. Most just take what they are given and stew in the background.
Silly me I don't. So in the end my opinion doesn't count for anything.
You' do what you do. Do what a lot of shareware do, use a two track
method. designate one for older versions and one for newer versions.

You can create a one with all the fancy new stuff. Then one for us poor
people that can drop 3k at the drop of the hat and have to hang on to
older equipment out of necessity.


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

Justin Wood (Callek)

unread,
Feb 5, 2010, 2:38:40 PM2/5/10
to
Phillip,

Realize that doing this plan now means that Mozilla will stop supporting
Firefox 3.6 (and thus 10.4) sometime in 2011. At least a year from now,
possibly even later than that.

It is surely not "drop of a hat".

-
~Justin Wood (Callek)

Asa Dotzler

unread,
Feb 5, 2010, 3:26:27 PM2/5/10
to
On 2/5/2010 8:17 AM, Phillip Jones wrote:

>
> And I am not the only one. I just happen to be the only one to voice an

If you had read Josh's post, you'd know that we all understand you are
no the only one. There are curerntly approximately 1.5 million people
using Firefox on 10.4 and we're fully aware of that.


> opinion. Most just take what they are given and stew in the background.
> Silly me I don't. So in the end my opinion doesn't count for anything.
> You' do what you do. Do what a lot of shareware do, use a two track
> method. designate one for older versions and one for newer versions.

Does this suggestion come with a donation for doubling of full-time
development resources, QA and testing, build and release infrastructure,
and user support for this second track that would cover a shrinking
minority of Firefox on Mac users?


> You can create a one with all the fancy new stuff. Then one for us poor
> people that can drop 3k at the drop of the hat and have to hang on to
> older equipment out of necessity.

If you cannot afford to "drop 3k at the drop of a hat" perhaps you can
afford to save up over the next year or so while this transition happens
so you can by a newer Mac (Apple has refurbished iMacs running Snow
Leopard for ~USD850
http://store.apple.com/us/browse/home/specialdeals/mac In a year, I'll
bet you could find one for half that price.)

That being said, I suspect that any sane outcome of this discussion will
have to prioritize Mozilla's project resources over your personal resources.

- A

Phillip Jones

unread,
Feb 5, 2010, 3:51:50 PM2/5/10
to
Asa Dotzler wrote:
> On 2/5/2010 8:17 AM, Phillip Jones wrote:
>
>>
>> And I am not the only one. I just happen to be the only one to voice an
>
> If you had read Josh's post, you'd know that we all understand you are
> no the only one. There are currently approximately 1.5 million people

> using Firefox on 10.4 and we're fully aware of that.
>
>
>> opinion. Most just take what they are given and stew in the background.
>> Silly me I don't. So in the end my opinion doesn't count for anything.
>> You' do what you do. Do what a lot of shareware do, use a two track
>> method. designate one for older versions and one for newer versions.
> Does this suggestion come with a donation for doubling of full-time
> development resources, QA and testing, build and release infrastructure,
> and user support for this second track that would cover a shrinking
> minority of Firefox on Mac users?

If I had the funds I'd sure give a donation.

You have to remember that, with today's recession while many people are
buying computers. There are many more such as I, that are having to use
old equipment.

-------------------snip-------------------

> That being said, I suspect that any sane outcome of this discussion will
> have to prioritize Mozilla's project resources over your personal resources.
>
> - A

That's what I suspected. That no matter what opinion is given it doesn't
make a difference. It will happen regardless of 1.5 million people needs
(not want).

I don't know why I tilt at windmills, it does no good. :-(

Anthony Hughes

unread,
Feb 5, 2010, 4:39:09 PM2/5/10
to
Just to be clear on this, Mozilla is officially dropping support in
1.9.3. Mozilla will not do anything to prevent someone (or many) in the
community from creating builds which will work on 10.4 -- correct?

Historically, Mozilla (the community) has been pretty awesome about
filling the voids which Mozilla (the company) creates out of necessity.

Cheers,

Anthony Hughes (:ashughes)
Jr QA Engineer, Mozilla QAE

Asa Dotzler

unread,
Feb 5, 2010, 4:49:25 PM2/5/10
to
On 2/5/2010 1:39 PM, Anthony Hughes wrote:
> Just to be clear on this, Mozilla is officially dropping support in
> 1.9.3. Mozilla will not do anything to prevent someone (or many) in the
> community from creating builds which will work on 10.4 -- correct?
>
> Historically, Mozilla (the community) has been pretty awesome about
> filling the voids which Mozilla (the company) creates out of necessity.
>
> Cheers,
>
> Anthony Hughes (:ashughes)
> Jr QA Engineer, Mozilla QAE


In this case, Mozilla already dropped it on the trunk and now the Module
Owner is proposing code removal. That means that it will be exceedingly
difficult for someone to just build a working Firefox 3.next for 10.4.
To do so would mean creating a branch before the code removal and then
keeping it fully in sync with the trunk. I don't see that happening.

- A

Justin Dolske

unread,
Feb 5, 2010, 4:52:42 PM2/5/10
to
On 2/4/10 9:16 PM, Josh Aas wrote:
> We
> have come to a point where we need to make a final decision and either
> restore 10.4 support or remove this (large) amount of 10.4 specific
> code.

So, this is another decision where it seems like knowing the plan/timing
for the next release might be useful...

It seems like if we were to ship a trunk release soon (Q2/3?), then
there could be a stronger argument for retaining 10.4 support. But if
the next trunk release is more of a 2011 thing, then there's less of a
reason to support 10.4.

As a historical data point, I dug up some posts from when we discussed
dropping 10.3 support for Firefox 3.0, back in May/June 2007...

http://groups.google.com/group/mozilla.dev.planning/msg/c19ecb46e27dbf91
http://groups.google.com/group/mozilla.dev.planning/msg/4bd908b72a5e0759

At the time, it was ~3.5 years since 10.3 had been released, Firefox 3.0
was expected to be ~6 months away (reality was 1 year). AUS data
indicated that 16% of Firefox users were running 10.3.

Now it's ~3.5 years since 10.4 was released, ?? months until Firefox ?.?
ships, and Josh's data indicates that 25% of our current users are on
10.4 (but that early signs are that it's much lower for 3.6).

So, offhand it seems reasonable to me, and roughly comparable to what we
did w.r.t 3.0/10.3. It would give me greater confidence to see what
happens with 3.6 uptake and .Next release schedule, but that's offset by
3.6 being a much better version for 10.4 users to be "stuck" at than 2.0
was for 10.3 users.

Justin

Joe Drew

unread,
Feb 5, 2010, 4:54:36 PM2/5/10
to Asa Dotzler, dev-pl...@lists.mozilla.org

On Feb 5, 2010, at 4:49 PM, Asa Dotzler wrote:
> In this case, Mozilla already dropped it on the trunk and now the Module Owner is proposing code removal. That means that it will be exceedingly difficult for someone to just build a working Firefox 3.next for 10.4. To do so would mean creating a branch before the code removal and then keeping it fully in sync with the trunk. I don't see that happening.

I've seen crazier things. :)

http://www.depublic.com/mozilla-macos9/

Robert Strong

unread,
Feb 5, 2010, 5:05:06 PM2/5/10
to dev-pl...@lists.mozilla.org
On 2/5/2010 1:52 PM, Justin Dolske wrote:
> On 2/4/10 9:16 PM, Josh Aas wrote:
>> We
>> have come to a point where we need to make a final decision and either
>> restore 10.4 support or remove this (large) amount of 10.4 specific
>> code.
>
> So, this is another decision where it seems like knowing the
> plan/timing for the next release might be useful...
>
> It seems like if we were to ship a trunk release soon (Q2/3?), then
> there could be a stronger argument for retaining 10.4 support. But if
> the next trunk release is more of a 2011 thing, then there's less of a
> reason to support 10.4.
>
> As a historical data point, I dug up some posts from when we discussed
> dropping 10.3 support for Firefox 3.0, back in May/June 2007...
>
> http://groups.google.com/group/mozilla.dev.planning/msg/c19ecb46e27dbf91
> http://groups.google.com/group/mozilla.dev.planning/msg/4bd908b72a5e0759
>
> At the time, it was ~3.5 years since 10.3 had been released, Firefox
> 3.0 was expected to be ~6 months away (reality was 1 year). AUS data
> indicated that 16% of Firefox users were running 10.3.
>
> Now it's ~3.5 years since 10.4 was released, ?? months until Firefox
> ?.? ships, and Josh's data indicates that 25% of our current users are
> on 10.4 (but that early signs are that it's much lower for 3.6).
For clarity, isn't the 25% of current users on 10.4 actually 25% of
current Mac users (also the previously mentioned 16%)?

Robert

Boris Zbarsky

unread,
Feb 5, 2010, 5:09:14 PM2/5/10
to
On 2/5/10 5:05 PM, Robert Strong wrote:
> For clarity, isn't the 25% of current users on 10.4 actually 25% of
> current Mac users (also the previously mentioned 16%)?

Yes.

-Boris

Boris Zbarsky

unread,
Feb 5, 2010, 5:10:05 PM2/5/10
to
On 2/5/10 4:52 PM, Justin Dolske wrote:
> It seems like if we were to ship a trunk release soon (Q2/3?), then
> there could be a stronger argument for retaining 10.4 support. But if
> the next trunk release is more of a 2011 thing, then there's less of a
> reason to support 10.4.

If whatever is shipping off trunk ships later than about end of Q3 or
beginning of Q4 of this year, then imho we've screwed up.

-Boris

Message has been deleted

Robert Kaiser

unread,
Feb 5, 2010, 7:07:30 PM2/5/10
to
Mulder wrote:
> While Mozilla may think that dropping support for Mac OS X 10.4 is a
> good idea, you're dead wrong. There is no need to do this

1) It's not about "good" vs. "bad" idea, it's about how much pain it is
to support 10.4, 10.5, 10.6 32bit and 10.6 64bit all at the same time,
and how much time we as a community can invest into developing for and
testing on all those systems - and all that in the end for a rather tiny
minority of our total users, which the whole Mac user base still is. We
all know that it's not a "good idea", the question is how much it is a
necessity for going forward overall, as we have limited resources.

2) How do you know there's "no need to do this"? Have you actually
looked at the code and found a way to easily support 10.4 in addition to
the newer systems? I'm sure Josh as our main Mac system support
developer would be very happy to see that option and its implementation
and would welcome your work on it.

Robert Kaiser

Forrest

unread,
Feb 5, 2010, 8:03:43 PM2/5/10
to
50% of the Mac's here can't run anything newer than OSX 10.4.x because
they're running a 700 MHz G3 and a 700 MHz G4 processor. One of these
machines is used on daily basis. I strongly suggest you rethink your
strategy of dropping OSX 10.4 support.

Judging from the comments I've read on some Mac support forums, most
folks say they're not happy with OSX 10.5 performance unless they're
running an Intel Mac - and those have only been shipping for 4 years.

JimR63701

unread,
Feb 5, 2010, 8:20:42 PM2/5/10
to
On Feb 4, 11:16 pm, Josh Aas <josh...@gmail.com> wrote:
> The approximately 25% of our Mac OS X users still on 10.4 would
> continue to be supported by Firefox 3.6 until that product reaches end
> of service, which won't be until several months after the next major
> version of Firefox is delivered (built on Gecko 1.9.3) later this
> year. Past data shows that we do not lose appreciable market share
> when we stop supporting a Mac OS X version. We are often one of the
> last vendors to continue supporting older Mac OS X releases, and I
> suspect that by the time this becomes an issue Apple may themselves
> have stopped issuing security updates for Mac OS X 10.4.
> We are planning to make the decision to remove 10.4 support final and
> remove the code from the tree. If you have any strong objections
> please let us know now.

I would object, since I am using an older PowerPC PowerBook under
10.4, and even 3.6 seems a bit slow or buggy to me. I am still in
process of checking if some add-ons are part of this, but since I
prefer ad-blocking and script-blocking, etc., if Firefox drops 10.4
support, I will have to look elsewhere instead of staying with
FIrefox, as I cannot afford a new(er) 'Book at this point in time. In
case somebody missed it, money is not flowing like water for the
majority of us out here (though that might not apply to all, I'm
sure).

I'd rather stay with Firefox, but if support for Tiger (which doesn't
require me to buy a GHz CPU-ed G4 or above) is dropped, you'll find me
on the other side of your imposed digital divide. Sorry to see that
this is being considered, since with Firefox being available for my
'Book and also for the (newer) Wintel box I have to use at work, I
have been able to maintain similarity of commands between the two
platforms with Firefox.

JimR63701

unread,
Feb 5, 2010, 8:24:57 PM2/5/10
to
On Feb 5, 6:07 pm, Robert Kaiser <ka...@kairo.at> wrote:
> 1) It's not about "good" vs. "bad" idea, it's about how much pain it is
> to support 10.4, 10.5, 10.6 32bit and 10.6 64bit all at the same time,
> and how much time we as a community can invest into developing for and
> testing on all those systems - and all that in the end for a rather tiny
> minority of our total users, which the whole Mac user base still is. We
> all know that it's not a "good idea", the question is how much it is a
> necessity for going forward overall, as we have limited resources.
>
> 2) How do you know there's "no need to do this"? Have you actually
> looked at the code and found a way to easily support 10.4 in addition to
> the newer systems? I'm sure Josh as our main Mac system support
> developer would be very happy to see that option and its implementation
> and would welcome your work on it.
>
> Robert Kaiser

Robert, your own bias appears to be showing... (Not meant as a
criticism, but the reality is, it's not "your ox that's being gored",
as you don't seem to have any personal investment on behalf of the Mac
version)

Asa Dotzler

unread,
Feb 5, 2010, 8:50:56 PM2/5/10
to
On 2/5/2010 5:03 PM, Forrest wrote:
> 50% of the Mac's here can't run anything newer than OSX 10.4.x because
> they're running a 700 MHz G3 and a 700 MHz G4 processor. One of these
> machines is used on daily basis. I strongly suggest you rethink your
> strategy of dropping OSX 10.4 support.

We have much better statistics than your anecdotal evidence of usage. If
you'd read the original post carefully, you'd have seen that we have
fairly precise numbers for people using Firefox on 10.4 and so your
advocacy on this front with far less precise numbers isn't helpful.


> Judging from the comments I've read on some Mac support forums, most
> folks say they're not happy with OSX 10.5 performance unless they're
> running an Intel Mac - and those have only been shipping for 4 years.


10.5 and 10.6 far outweigh 10.4 according to all of the publicly
available measures.

Over 80% of Macs, as reported here
http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=10
are running 10.5 or 10.6 and those running 10.4 are dropping off at
about 10% per month.
http://marketshare.hitslink.com/report.aspx?qprid=11&qpcustom=Mac%20OS%20X%2010.4&qptimeframe=M&qpsp=122&qpnp=12

In one year, I expect 10.4 to account for less than 5% of Mac OS X users
and at that point it will have less prominence than Windows 98.

- A

Asa Dotzler

unread,
Feb 5, 2010, 9:00:46 PM2/5/10
to
On 2/5/2010 5:20 PM, JimR63701 wrote:
> On Feb 4, 11:16 pm, Josh Aas<josh...@gmail.com> wrote:
>> The approximately 25% of our Mac OS X users still on 10.4 would
>> continue to be supported by Firefox 3.6 until that product reaches end
>> of service, which won't be until several months after the next major
>> version of Firefox is delivered (built on Gecko 1.9.3) later this
>> year. Past data shows that we do not lose appreciable market share
>> when we stop supporting a Mac OS X version. We are often one of the
>> last vendors to continue supporting older Mac OS X releases, and I
>> suspect that by the time this becomes an issue Apple may themselves
>> have stopped issuing security updates for Mac OS X 10.4.
>> We are planning to make the decision to remove 10.4 support final and
>> remove the code from the tree. If you have any strong objections
>> please let us know now.
>
> I would object, since I am using an older PowerPC PowerBook under
> 10.4, and even 3.6 seems a bit slow or buggy to me. I am still in
> process of checking if some add-ons are part of this, but since I
> prefer ad-blocking and script-blocking, etc., if Firefox drops 10.4
> support, I will have to look elsewhere instead of staying with
> FIrefox, as I cannot afford a new(er) 'Book at this point in time. In
> case somebody missed it, money is not flowing like water for the
> majority of us out here (though that might not apply to all, I'm
> sure).


Since this decision won't be made because a few users visiting this
forum are still bound to 10.4, this kind of advocacy doesn't help much.
If you can add more precise usage data to this discussion than what
Josh offered in the initial post, please do. If you know of other kinds
of data that represents large numbers of Mac or Firefox users that
hasn't already been mentioned, please add that.


> I'd rather stay with Firefox, but if support for Tiger (which doesn't
> require me to buy a GHz CPU-ed G4 or above) is dropped, you'll find me
> on the other side of your imposed digital divide. Sorry to see that
> this is being considered, since with Firefox being available for my
> 'Book and also for the (newer) Wintel box I have to use at work, I
> have been able to maintain similarity of commands between the two
> platforms with Firefox.

Obviously some users will always be left behind when we unsupport a
platform.

I (and I'm sure others here) recognize that tens or even hundreds of
thousands of users will be left behind in a year or so if we stop
support for 10.4. We understand that. If we tried to support 100% of
operating systems out there, the project would collapse.

That means we have to pick our target versions carefully. Do you have
some suggestion about what that cut-off should be that goes further than
"not the platform I'm on" ?

- A

Asa Dotzler

unread,
Feb 5, 2010, 9:05:18 PM2/5/10
to
On 2/5/2010 3:18 PM, Mulder wrote:
> While Mozilla may think that dropping support for Mac OS X 10.4 is a
> good idea, you're dead wrong. There is no need to do this; it's a
> short-sighted plan to avoid supporting well over a million users who
> are still running 10.4 for various reasons;

And you think it will still be well over 1 million users a year from now?


>
> You can't claim poverty, either. Mozilla takes in many millions of
> dollars per year from Google by having their search engine as the
> default in Firefox, so don't even try to use that as a justification
> for keeping your software working.


No one is claiming poverty. We are talking about how we best utilize our
limited resources. I can count the serious Mac platform experts we have
on one hand and splitting those resources more than is critically
necessary isn't something I'm excited about. One of those top experts is
making this proposal and I doubt he'd be making it if he thought we had
the resources to easily support 10.4 and 10.5&6.


> If you're going to drop support for 10.4 no matter what people say,
> then what's the point of asking for our feedback? When you can explain
> that, you might be getting to the root of the problem: yourselves.

Can you provide further insight than we already have into the number of
people using 10.4 or using Firefox on 10.4 or into Apple's future
support schedule or how much work is actually involved in maintaining
support for 10.4? Those kinds of things would be useful feedback. "I'm
on 10.4 so you're stupid for dropping it in a year" isn't valuable
feedback.

- A

Phillip Jones

unread,
Feb 5, 2010, 10:17:27 PM2/5/10
to
Although the Mac OS is UNIX (FreeBSD UNIX).

User of the Mac OS do not typically use UNIX They use the Mac GUI
(Finder) to view files and operate applications. I've been a Mac USER
since about 1986 and I've yet create a Build.
we have two ways of installing programs. DMG (pronounced DIM-edge) and
stands of Disk Image the overwhelming majority of the way applications
are delivered; and PKG (Package). Unless we are application developers.

That's the only way deal with programs. with the possible exception of
Apple-scripts and automator actions. I've only dealt with two or three
apple-script and those were given to me; all I had to do was compile and
run them using the Script Editor. I've yet to use Autmator actions for
anything (unless they are done behind the scenes).

Anthony Hughes wrote:
> Just to be clear on this, Mozilla is officially dropping support in
> 1.9.3. Mozilla will not do anything to prevent someone (or many) in the
> community from creating builds which will work on 10.4 -- correct?
>
> Historically, Mozilla (the community) has been pretty awesome about
> filling the voids which Mozilla (the company) creates out of necessity.
>
> Cheers,
>
> Anthony Hughes (:ashughes)
> Jr QA Engineer, Mozilla QAE
>
> On 05/02/2010 12:51 PM, Phillip Jones wrote:

-------------------snip-------------------

>> I don't know why I tilt at windmills, it does no good. :-(
>

Phillip Jones

unread,
Feb 5, 2010, 10:21:54 PM2/5/10
to

Not at Mozilla. When they have their head set on doing something
complaints against doing so does no good. I've never seen where typical
user input influenced anything.

Phillip Jones

unread,
Feb 5, 2010, 10:25:52 PM2/5/10
to
the 16% are users of other Mac OSes as related to all OS of any type
supported.
The 800 pound Gorilla being MS-DOS. Then Mac then UNIX, then Linux and so on

Phillip Jones

unread,
Feb 5, 2010, 10:34:46 PM2/5/10
to
Asa Dotzler wrote:
> On 2/5/2010 3:18 PM, Mulder wrote:
>> While Mozilla may think that dropping support for Mac OS X 10.4 is a
>> good idea, you're dead wrong. There is no need to do this; it's a
>> short-sighted plan to avoid supporting well over a million users who
>> are still running 10.4 for various reasons;
>
> And you think it will still be well over 1 million users a year from now?

If the economy doesn't get better - yes.

-------------------snip-------------------

> - A

AppleManifesto17

unread,
Feb 6, 2010, 12:50:10 AM2/6/10
to


If you are working with Apple's latest Xcode 3.2.2 and SDK's 10.4
Tiger support is not enabled by default. Leopard and Snow Leopard are
actually substantially different than Tiger really when you look at
all the Core Frameworks, I think they should really just worry about
innovation, speed, and using the very latest technology rather than
supporting and older OS and old technology if not they will really
just suffer the fate of MS, stop supporting legacy software and move
on with the latest technology, hardware, and software (OS included);
the browser "wars" are very competitive! I feel bad for those who
cannot upgrade, but no need to slow the pace of innovation for those
who can upgrade and are new to the Mac platform.

Teoli

unread,
Feb 6, 2010, 1:35:10 AM2/6/10
to
On 06.02.10 01:07, Robert Kaiser wrote:
> it's about how much pain it is to support 10.4, 10.5, 10.6 32bit
> and 10.6 64bit all at the same time,

I think you should also take in account the Intel/PPC support.

It means that keeping 10.4, Mozilla have to test/support:
10.4 PPC
10.4 x86
10.5 PPC
10.5 x86
10.5 x64
10.6 x86
10.6 x64

Abandoning 10.4, means 29% of OS/CPU combination less.

If concerns arise about the 10.4 user base, extend the security-fix
support of 3.6 from mid-2011 to end-2011, it should be less work (but
still work) to maintain an old branch for security rather than to
back-port anything new; especially as other products (Tb?) may still
need Gecko 1.9.3 by then.

Note that I don't know if you plan to support x64 on 10.5. I don't think
it is useful.

--
Teoli

Sonic Purity

unread,
Feb 6, 2010, 2:48:50 AM2/6/10
to
On Feb 4, 9:16 pm, Josh Aas <josh...@gmail.com> wrote:
> Where
> we can work around supporting 10.4, doing so consumes valuable time
> and effort. Neither Chrome nor Safari has to deal with this.

Actually this is factually incorrect for Safari: the current version
of Safari is 4.0.4. It is fully supported on OS 10.4.11 on PPC and
Intel Macs. I am running it right now on a 1999 G4 AGP 450 MHz, which
is my primary OS X Mac. I support a number of clients/family/friends,
few of whom have Intel Macs and most of whom are running Tiger (and
this same version of Safari). Safari V.4 is actually working better on
the old Macs i deal with (directly or indirectly) than late versions
of Safari 3.

Still, that number of users is invisible compared to the numbers of
users of other OS versions/platforms that the people working on
Mozilla are dealing with. While it would be nice to see continued
support for Tiger and while i am a fierce trailing-edge user who
champions keeping older systems going as long as possible, i am also
well aware that legacy support can be at least a drain and possibly a
project killer as has been pointed out. I personally trust those who
are active with the Mozilla project to make wise decisions to keep a
reasonable balance, so while i vote very strongly for Tiger support
and would personally benefit from it (as would my clients/family/
friends nearly to a person), i have no hard facts/numbers to sway the
discussion and do understand that it may be in the best interests of
the project and majority of users to drop Tiger and move forward.

Teoli

unread,
Feb 6, 2010, 4:08:41 AM2/6/10
to
On 06.02.10 08:48, Sonic Purity wrote:
> On Feb 4, 9:16 pm, Josh Aas<josh...@gmail.com> wrote:
>> Where
>> we can work around supporting 10.4, doing so consumes valuable time
>> and effort. Neither Chrome nor Safari has to deal with this.
>
> Actually this is factually incorrect for Safari: the current version
> of Safari is 4.0.4. It is fully supported on OS 10.4.11 on PPC and
> Intel Macs.
You mixed it. The discussion is not going about Firefox 3.6.x supporting
OS 10.4 or not (it does, and will), but about Firefox.next (being 3.7 or
4.0), supporting it.

The comparison to Safari lead then to the question:
"Will Safari *5* support 10.4?"

I don't have the answer (Apple doesn't comment on future products).

But my sentiment is no, Safari 5 will very likely not work on OS 10.4,
neither on PPC. It may even be a 64-bit only release.

Philippe Wittenbergh

unread,
Feb 6, 2010, 4:16:58 AM2/6/10
to dev-pl...@lists.mozilla.org

On Feb 6, 2010, at 6:08 PM, Teoli wrote:

> You mixed it. The discussion is not going about Firefox 3.6.x supporting OS 10.4 or not (it does, and will), but about Firefox.next (being 3.7 or 4.0), supporting it.
>
> The comparison to Safari lead then to the question:
> "Will Safari *5* support 10.4?"
>
> I don't have the answer (Apple doesn't comment on future products).
>
> But my sentiment is no, Safari 5 will very likely not work on OS 10.4,
> neither on PPC. It may even be a 64-bit only release.

Fwiw, the latest nightly builds of WebKit still run (fine) on 10.4.11 (I can't test how well they run, but they do run).

http://nightly.webkit.org/

Philippe
---
Philippe Wittenbergh
http://l-c-n.com/

Gijs Kruitbosch

unread,
Feb 6, 2010, 5:37:38 AM2/6/10
to
On 05/02/2010 22:52 PM, Justin Dolske wrote:
> <snip>

> As a historical data point, I dug up some posts from when we discussed
> dropping 10.3 support for Firefox 3.0, back in May/June 2007...
>
> http://groups.google.com/group/mozilla.dev.planning/msg/c19ecb46e27dbf91
> http://groups.google.com/group/mozilla.dev.planning/msg/4bd908b72a5e0759
>
> At the time, it was ~3.5 years since 10.3 had been released, Firefox 3.0
> was expected to be ~6 months away (reality was 1 year). AUS data
> indicated that 16% of Firefox users were running 10.3.
>
> Now it's ~3.5 years since 10.4 was released, ?? months until Firefox ?.?
> ships, and Josh's data indicates that 25% of our current users are on
> 10.4 (but that early signs are that it's much lower for 3.6).
>
> So, offhand it seems reasonable to me, and roughly comparable to what we
> did w.r.t 3.0/10.3.
><snip>


I'm confused. AIUI, per what Boris said, ?.? (from trunk) will ship in Q2/Q3,
which is at most 2/3 of a year away. 25% of users rather than 16% of users use
it. If I had to guess at the overall size of the mac Fx userbase, I'd say it has
grown since that 3.0 decision point (if someone has solid data from AUS, please
share).

So, all in all, if we drop 10.4 support, we remove support for a significantly
greater (10 pct points) minority of our userbase, which is also a significantly
larger group of people (in absolute terms), at a significantly (33%) faster pace
than when 10.3 support was removed.

I don't see how that is "roughly comparable". What am I missing?

I'm not saying it's not the right thing to do because I'm honestly not sure what
the cost of the 10.4 support is. I do think the numbers are food for thought.

~ Gijs


(for full disclosure: I'm typing this on a 10.6 macbook, which was upgraded from
10.4 using the $30 upgrade dvd your average apple store will sell you. Obviously
won't work for 10.4 ppc users - would be interesting to see how many of them
there are?)

Dao

unread,
Feb 6, 2010, 7:04:44 AM2/6/10
to
On 06.02.2010 02:20, JimR63701 wrote:
> I would object, since I am using an older PowerPC PowerBook under
> 10.4, and even 3.6 seems a bit slow or buggy to me.

This seems to indicate that we can't effectively support 10.4 already,
doesn't it? So are you suggesting that we should /increase/ the
investment in 10.4 support?

Mike Shaver

unread,
Feb 6, 2010, 7:54:36 AM2/6/10
to Gijs Kruitbosch, dev-pl...@lists.mozilla.org
On Sat, Feb 6, 2010 at 5:37 AM, Gijs Kruitbosch
<gijskru...@gmail.com> wrote:
> I'm confused. AIUI, per what Boris said, ?.? (from trunk) will ship in
> Q2/Q3, which is at most 2/3 of a year away. 25% of users rather than 16% of
> users use it. If I had to guess at the overall size of the mac Fx userbase,
> I'd say it has grown since that 3.0 decision point (if someone has solid
> data from AUS, please share).

10.4 users would still have a supported release until FF 3.6 was
end-of-lifed, which I would expect to be at least 6 months after the
trunk release of which Boris speaks. They wouldn't be able to upgrade
to the latest and greatest, but they would still get stability and
security updates.

Mike

Message has been deleted

L. David Baron

unread,
Feb 6, 2010, 1:57:14 PM2/6/10
to dev-pl...@lists.mozilla.org
On Sunday 2010-02-07 00:19 +1300, Blair McBride wrote:
> There may well be 1 million users using 3.5 and 3.6 in a year's
> time. And those versions will continue to support 10.4. But the
> majority of those on 10.4 won't upgrade to 3.next, even if it has
> 10.4 support. As it is, very few 10.4 users upgraded to 3.6. Looking
> at the numbers, 24% of 3.5 Mac users run 10.4; while only 12% of 3.6
> Mac users run 10.4. I'd say 6% on 3.next would be a very optimistic
> number - and at great development cost.

I think numbers for Firefox 3.6 users will change substantially once
we make a prompted major update offer from 3.5 to 3.6. Please note
that the 3.6 numbers Josh posted were much smaller than the 3.5
numbers (basically 5.2% of the 3.5+3.6 users were on 3.6, and 94.8%
were on 3.5).

The 3.6 users right now are presumably largely people who are
interested enough in technology that they read sources of news that
told them about the 3.6 release, users who I'd expect are more
likely to be on the cutting edge in terms of OS versions as well.

-David

--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/

Phillip Jones

unread,
Feb 6, 2010, 2:16:10 PM2/6/10
to

I am type person that updates either automatically through auto update
or going to web site and updating. In in the Past I tested nightly until
I figured what I said about bugs or suggestion were laughed at or
ignored. since users don't know anything.

Shawn Wilsher

unread,
Feb 6, 2010, 2:18:03 PM2/6/10
to dev-pl...@lists.mozilla.org
On 2/6/2010 6:44 AM, Mulder wrote:
> If you currently have limited resources (programmers), try using some
> of the $25 million or more you collect every year from Google to hire
> more Mac OS X programmers. Not only would that add to the expertise
> you have, it would make your development cycle move faster.
>
>
Have you read The Mythical Man Month? Adding more people will not make
us move faster in the short term, and it may not in the long term either.

Besides that, you are arguing that we should spend a large sum of money
on small percentage of our users (a shrinking percentage at that). What
would you say to all of our windows users who would then see less
resources devoted to them?
> You might not currently have the resources you need to support all
> three versions, but you have more than enough money to get those
> resources; all it takes is the courage to do it and the willingness to
> support your users. Alienating users by dropping support when there's
> no valid technological reason only makes more users unhappy and causes
> them to switch again to another browser, which is a never-ending
> cycle.
>
I'm sorry, but Josh covered the technical reasons in his first post.
You can certainly try to argue that they aren't issues, but simply
dismissing them is not the way to do that.

> I can't see the future, so I have no idea what the usage numbers will
> be, just as you have no idea. I'm sure you're well aware that Apple
> doesn't comment on future plans and I certainly can't make them talk.
> I do know that there are millions of Mac OS X 10.4 users who either
> cannot or will not upgrade, for a variety of reasons, all of them
> perfectly valid for their needs. I also know that Mac OS X 10.5 and
> 10.6 are riddled with serious bugs and had features removed without
> notice; something Apple doesn't publicize or disclose to anyone before
> or after they purchase the OS or a system with those versions
> installed. Users are left to discover it on their own, and it's always
> when they need it to work correctly; that's too late.
>
What are these serious bugs and removed features you speak of? If you
are trying to convince us that this is a serious issue, I suggest you
make actual claims instead of hand-wavy references to problems that come
across as FUD.

> So the question you need to ask yourselves before pursuing this ill-
> considered idea is: "Do you want to spend the money to hire the
> programmers you need to support 10.4, or do you want to give up
> millions in revenue?"
>
It's not even about hiring programmers. It's also about buying more
hardware, and supporting it. It's also about using our resources in the
most beneficial way for our users. You are arguing that we should spend
a disproportionate amount of our resources on a small and shrinking
(even if the number of 10.4 users stays the same, they will make up a
smaller percentage of our users over time) percentage of our user base.
We are not a massive corporation like Apple, so we have to use our
limited resources in the best possible way for our users.

Cheers,

Shawn

Justin Dolske

unread,
Feb 6, 2010, 4:43:13 PM2/6/10
to
On 2/6/10 2:37 AM, Gijs Kruitbosch wrote:

> I don't see how that is "roughly comparable". What am I missing?

I suspect the 25% figure is high, because there's not much 3.6 data yet.
The 3.6 data currently has only 12% of OS X users on 10.4... No great
surprise that early adopters are not running 10.4. As 3.6 gains uptake,
I'd expect 10.4 percentages to level off somewhere less than 25%, and of
that a similar fraction of users wouldn't be upgrading to 3.7/4.0 anyway.

I say "roughly" comparable because, well, they seem like roughly similar
percentages! :) I don't think these kinds of decisions require very
precise comparisons. "About a fifth" seems close enough to me.

Justin

Robert Kaiser

unread,
Feb 6, 2010, 6:13:00 PM2/6/10
to
JimR63701 wrote:
> Robert, your own bias appears to be showing... (Not meant as a
> criticism, but the reality is, it's not "your ox that's being gored",
> as you don't seem to have any personal investment on behalf of the Mac
> version)

It might, and I'm neither on a Mac nor on an even more-used OS in terms
of our numbers. Hell, I'm not even a Firefox user, but still a
Gecko-lover and Mozilla enthusiast.
In my project, 1.4 million daily users would be more than our
application has as a whole. But in Firefox world, 1.4 million daily
users on OS X 10.4 are not only less than a quarter of all Mac users,
but also an almost (!) insignificant number compared to the total daily
user number that is somewhere between 200 and 300 million, IIRC.
Of course, it's not completely insignificant or 10.4 would not work with
any current versions. It's even important enough that the just-released
Firefox 3.6 will - for its whole lifetime of probably still at least a
year - support this OS version fully, with add-ons, security updates and
everything. The same will probably be true for Thunderbird 3.1.

All the talk here is about the *next* version of Firefox and other
Mozilla applications, i.e. Firefox 3.7 (or higher), Thunderbird 3.2 (or
higher) and probably SeaMonkey 2.1 as well, all of which will not be
released before summer or fall this year, maybe even later. Note that
all future version numbers are tentative and can be changed at any time
(if so, usually to a higher number).

Robert Kaiser

Jean-Marc Desperrier

unread,
Feb 7, 2010, 4:47:05 AM2/7/10
to
On 05/02/2010 23:10, Boris Zbarsky wrote:
> If whatever is shipping off trunk ships later than about end of Q3 or
> beginning of Q4 of this year, then imho we've screwed up.

I know the team insist it will be able to meet that schedule, but it
only insisted till the very end that it would be able to meet the
November 2009 schedule for 3.6

IMO you will start stabilizing 3.7 toward the beginning of Q4, and
release it very end of 2010/early 2011. At best. But there's nothing
horrible in that. That's about the minimal interval between versions
that users can handle comfortably.

Boris Zbarsky

unread,
Feb 7, 2010, 9:08:04 AM2/7/10
to
On 2/7/10 4:47 AM, Jean-Marc Desperrier wrote:
> I know the team insist it will be able to meet that schedule

I think you have this backwards. My claim is that we should scope work
so as to fit that schedule.

Note that there is no "the team" here; there is just me making a claim
about what I think we should aim for.

> but it only insisted till the very end that it would be able to meet the
> November 2009 schedule for 3.6

I'm not sure what you're lumping under "the team" here, but the issue
there was partly picking the scope first and partly not stabilizing
until too late.

> IMO you will start stabilizing 3.7 toward the beginning of Q4, and
> release it very end of 2010/early 2011.

If we start stabilizing at the beginning of Q4 (so that would be October
2010) then we are not likely to ship anything until April 2011; more
likely May 2011.

We need to start stabilizing in May 2010 at the latest, again imo.

> But there's nothing horrible in that.

There is in terms of PR and being perceived as falling behind in
standards support and performance.

> That's about the minimal interval between versions
> that users can handle comfortably.

So you think the interval between 3.5 and 3.6 was too short to handle
comfortably?

-Boris

Message has been deleted

Boris Zbarsky

unread,
Feb 7, 2010, 11:25:43 AM2/7/10
to
On 2/7/10 10:37 AM, Mulder wrote:
> Nonsense. On the one hand you're arguing that you don't have the
> resources, and on the other you're saying that if you did have those
> resources it wouldn't help you.

Wouldn't help in the timeframe involved here.

That is, if we hired more people _today_ they would not be up to speed
in time to help.

In the long term, the main issue is that amount of work that can be done
scales sublinearly with number of people doing it. So in fact putting
more people on an issue requires "disproportionate" investment to get an
improvement, after a certain point.

> I'm not arguing that you should spend a disproportionate amount of
> resources on supporting 10.4 at all. I'm arguing that you already have
> the hardware to support Mac OS X 10.4

So you're arguing that support for 64-bit builds on 10.6, say, is less
important than support for 10.4? The point is that the resources
currently being used for 10.4 would be repurposed for better supporting
10.5 and 10.6. In particular, the hardware used for 10.4 and the
hardware needed for 64-bit 10.6 builds are about equivalent in terms of
number of machines and such.

> In the meantime, you're trying to convince people that you're
> suddenly going to lose those resources after 3.7 ships.

We are if we want to use them to support 10.6 64-bit builds.

> you just don't want to use it to support 10.4 users

Right, because we feel that there is a bigger user demographic that
would be better served by it.

Note that the hardware is not a huge issue, by the way; the fact that
you have to structure the code very differently to work on 10.4 and 10.6
(_especially_ 10.6 64-bit) is a much bigger problem.

> You could just as
> easily drop support for Firefox for Windows and see if that forces all
> those users to get a new Mac. I'm betting it won't.

Of course it won't. I don't see what that has to do with the discussion
here, though.

> The notion that your 10.4 users are a small percentage of Firefox
> users may be true, but at this point you can only infer that user base
> will shrink

That seems like a good bet, since the actual number of 10.4 users is
likely to be shrinking. It's not like people are buying many new 10.4
installs out there.

> You don't have billions in cash like Apple, but you do have a lot more
> money than indie software developers, so you should make your product
> work on as many versions of Mac OS X as possible

That's a non-sequitur, sorry. We should make our product work as well
as it can for as many of our users as it can. The question is what to
do when those two goals are in conflict, as here. We can significantly
improve the user experience on 10.5 and especially 10.6 if we drop
support for 10.4 (we're talking something like 30% performance
improvement on 10.6, for example if I recall the numbers correctly,
between the newer compiler and doing 64-bit builds). Which of those is
more important? It really depends on one's point of view, obviously.

> especially if Apple
> is still supporting those versions with security updates or browser
> updates, as they are with 10.4.

No one's talking about dropping 10.4 support right now. The discussion
is about dropping support for it in late spring 2011 or so at the earliest.

Sadly, that involves guessing what Apple will do. Guessing wrong one
way means we drop support for users whose OS is still supported.
Guessing wrong the other way means we invest a lot of time into users
whose OS is no longer supported and shortchange other users.

Welcome to life. It's full of hard choices. What Josh is asking for
here is any information anyone might have that has not been brought up
yet (of which I have seen none in this thread so far) that will affect
the decision that has been made thus far based on the information that
has already been raised before.

-Boris

Boris Zbarsky

unread,
Feb 7, 2010, 11:39:37 AM2/7/10
to
On 2/7/10 10:37 AM, Mulder wrote:
> You're probably spending more time and resources on supporting a crappy OS
> (Windoze), because Microsoft doesn't know how to make a decent OS

And just for the record, we're putting in a lot more work into our Mac
support than Windows support, on a per-user basis. If we hired 2 more
people to do Mac stuff, we'd be putting in more work in absolute terms too.

The fact is, the changes between Mac OS versions are _huge_; supporting
multiple versions of Mac OS at once is a huge pain (supporting 10.4 and
10.6 at once is about like supporting Win98 and Win7 at once, if not
harder).

-Boris

Daniel Veditz

unread,
Feb 7, 2010, 12:20:28 PM2/7/10
to pjo...@kimbanet.com
On 2/6/10 11:16 AM, Phillip Jones wrote:
> In in the Past I tested nightly until I figured what I said about
> bugs or suggestion were laughed at or ignored. since users don't
> know anything.

I'm sorry you had that experience -- no one should be laughing at
anyone trying to give good feedback.

Message has been deleted

Brad Lassey

unread,
Feb 7, 2010, 1:49:26 PM2/7/10
to

> Then you're acknowledging publicly that it doesn't matter what users
> say, you're going to do something that you already decided to do
> before asking for input. Choices may be hard, but when you ask for
> user input, you should at least listen to the wishes of the users, not
> your own predetermined decision. Welcome to the ranks of hypocrisy.
>
There is a difference between having your wishes and opinions listened
to and having them change the proposed decision, please don't confuse
the two.

The fact of the matter is that the people who originally posted asking
for feedback have already researched the pros and cons of this decision
to the best of their ability. It is the realm of possibility that they
missed some crucial fact, but thus far such an oversight has not been
pointed out (as far as I can tell anyway).

-Brad

Message has been deleted

johnjbarton

unread,
Feb 7, 2010, 2:02:25 PM2/7/10
to

But it is common nevertheless. And 'ignored' is even more common.

jjb

Zack Weinberg

unread,
Feb 7, 2010, 2:29:24 PM2/7/10
to johnjbarton, dev-pl...@lists.mozilla.org
johnjbarton <johnj...@johnjbarton.com> wrote:

Yup. And it only takes one bad bugzilla (or support forum) experience
to put a user off contacting us *forever*, & they will tell all their
friends not to bother trying to give us feedback, too.

IMO a good start toward fixing this would be to change the Bugzilla
etiquette guidelines so that under no circumstances short of actual
spam is it acceptable to tell anyone to stop commenting on a bug.

zw

Boris Zbarsky

unread,
Feb 7, 2010, 2:32:52 PM2/7/10
to
On 2/7/10 1:34 PM, Mulder wrote:
> I find that hard to believe. I know many Mac programmers with years of
> experience, having worked for Adobe, Apple, etc on major applications,
> include Adobe Illustrator and iMovie. They're out there and available
> for the right price.

<shrug>. All I know is that finding competent people who are also
willing to work in our environment (e.g. actually working with the
community, not getting commit access the day that they get hired, etc)
is not being particularly easy. I can't speak to the pricing, since I'm
not involved in those decisions.

> Yes, they are less important. 64-bit is strictly hype, there is no
> benefit to the average user.

Given that trivial performance measurements show that 64-bit builds are
a good bit faster than 32-bit once on just about any metric you care to
measure (Sunspider, Dromaeo, pageload performance), I wonder where
you're getting your data.

As wikipedia likes to say, "citation needed".

For the specific case of 64-bit builds on Mac,
http://boomswaggerboom.wordpress.com/2009/10/01/64-bit-firefox-performance-on-mac-os-x/
has some data from October 2009. Note that the Tjss score there is
sunspider; Tsunspider is something somewhat different, confusingly enough.

> You don't need to support 64-bit builds, because users gain nothing by
> using 64-bit applications.

This is particularly false on Mac OS 10.6, which comes with most of its
default apps 64-bit by default. As a result we get the very specific
gain that starting Firefox doesn't have to load all the 32-bit
compatibility libraries (which significantly improves the
cold-start-after-computer-on performance of Firefox), in addition to the
general "it's got more registers so the compiler can do a better job"
speedups linked to above. Loading those libraries involves a lot more
disk access and significantly slows down startup.

> The only exception is a very narrow subset
> of all users that use resource-intensive applications such as those
> for motion graphics, RAW image processing, and even film editing, that
> are designed to get a performance boost from it.

Citation needed.

> It has everything to do with it, because what Mozilla plans to do is
> based on the assumption that it will spur 10.4 users to switch to
> 10.6

No, there is no such assumption. The only assumption in this vein is
that users will either switch to 10.5 or 10.6 or not, completely
independently of what we do, and that the net effect is that about 18
months from now the fraction of our Mac userbase on 10.4 will be smaller
than either that on 10.5 or on 10.6.

The former assumption seems like a good one to me (I doubt many current
10.5 or 10.6 users will be going back to 10.4). The latter is already
true; see the numbers Josh cited. How _much_ smaller the 10.4 user base
will is open to debate; predicting the future is hard.

> So if you think that tactic will work with
> Mac users, there's no reason you shouldn't do the inverse and impose
> it on Windoze users and see if they buy a Mac instead.

This suggestion seems to be based on a fundamental misunderstanding, per
above.

> Then you're acknowledging publicly that it doesn't matter what users
> say, you're going to do something that you already decided to do
> before asking for input.

No. I'm saying that we're looking for _new_ input, that hasn't already
been brought up the last time this conversation happened and hasn't
already been taken into account.

> Choices may be hard, but when you ask for
> user input

Josh asked for "input". That's not necessarily the same thing as "user
input"; he's looking for input from users, extension developers,
whatever. But "I use 10.4 and it would suck for me" is not really
input; we _know_ there are people in that position.

> you should at least listen to the wishes of the users

Heck, I'm not just listening to what you're saying, I'm even responding
to it. There's a difference between "listening to X" and "doing
whatever X wants".

-Boris

Boris Zbarsky

unread,
Feb 7, 2010, 2:34:14 PM2/7/10
to
On 2/7/10 2:29 PM, Zack Weinberg wrote:
> IMO a good start toward fixing this would be to change the Bugzilla
> etiquette guidelines so that under no circumstances short of actual
> spam is it acceptable to tell anyone to stop commenting on a bug.

That's not necessarily workable. If X files a bug and Y tries along and
tries to hijack it, I think it's perfectly reasonable to ask Y to file a
separate bug (or file one) and ask Y to take the comments there.

-Boris

Mike Connor

unread,
Feb 7, 2010, 2:37:49 PM2/7/10
to Zack Weinberg, dev-pl...@lists.mozilla.org, johnjbarton

On 7-Feb-10, at 8:29 PM, Zack Weinberg wrote:

> Yup. And it only takes one bad bugzilla (or support forum) experience
> to put a user off contacting us *forever*, & they will tell all their
> friends not to bother trying to give us feedback, too.
>

> IMO a good start toward fixing this would be to change the Bugzilla
> etiquette guidelines so that under no circumstances short of actual
> spam is it acceptable to tell anyone to stop commenting on a bug.

There's a middle ground between "reject all feedback" and "will accept
endless advocacy comments." I agree we don't always handle negative
responses well, but newsgroups and other avenues other than our task
management system exist to handle feedback and discussion. Continued
venting/anger in bugs does not help anyone, and allowing it will not
help us in any measurable or imaginary way.

-- Mike

Zack Weinberg

unread,
Feb 7, 2010, 2:47:57 PM2/7/10
to Boris Zbarsky, dev-pl...@lists.mozilla.org
Boris Zbarsky <bzba...@mit.edu> wrote:

There's a huge difference between "This bug is about A, not B; please
(file a new bug for B | discuss B in bug NNNNN, which is about that)"
and "Stop complaining about this bug, it'll get fixed when it gets
fixed". The latter is what I think we should stop doing, *even though*
it means more nagging from bugmail.

zw

Zack Weinberg

unread,
Feb 7, 2010, 2:53:45 PM2/7/10
to Mike Connor, dev-pl...@lists.mozilla.org, johnjbarton
Mike Connor <mco...@mozilla.com> wrote:

> On 7-Feb-10, at 8:29 PM, Zack Weinberg wrote:
> > IMO a good start toward fixing this would be to change the Bugzilla
> > etiquette guidelines so that under no circumstances short of actual
> > spam is it acceptable to tell anyone to stop commenting on a bug.
>
> There's a middle ground between "reject all feedback" and "will
> accept endless advocacy comments."

From our perspective, yes.

From the perspective of each user who has gone to the trouble of
creating a bugzilla account so they can tell us that (insert your
favorite old bug here) is a problem for them too, only to be told
to go away, there is no difference.

Because of that, I think we need to permit, and possibly even respond
positively to, advocacy and venting in bugs EVEN THOUGH it is
unhelpful to the small group of people who use bugzilla as a task
queue.

Being ignored is arguably even worse than being told to go away. We
should be taking efforts up to and including hiring more support staff
in order to ensure that no one is ignored. Support scales more easily
than devs.

zw

Mike Connor

unread,
Feb 7, 2010, 2:54:40 PM2/7/10
to Zack Weinberg, Boris Zbarsky, dev-pl...@lists.mozilla.org

On 7-Feb-10, at 8:47 PM, Zack Weinberg wrote:

> There's a huge difference between "This bug is about A, not B; please
> (file a new bug for B | discuss B in bug NNNNN, which is about that)"
> and "Stop complaining about this bug, it'll get fixed when it gets
> fixed". The latter is what I think we should stop doing, *even
> though*
> it means more nagging from bugmail.

https://bugzilla.mozilla.org/show_bug.cgi?id=18574 is the pathological
end state for that type of behaviour.

Ultimately, nagging in bugs just makes bugs harder to read, and spams
everyone following the bug with unhelpful comments. If it doesn't
actually make a difference to fixing the bugs, why are the negatives
worth it? Again, there's more constructive ways to educate people,
but I've seen dozens, if not hundreds, of bugs, get to 100+ comments,
of which far less than half advance the fix for the bug in any way.
Unthrottling that type of comment would exacerbate the situation, and
I really am struggling to find a net positive outcome...

-- Mike

johnjbarton

unread,
Feb 7, 2010, 3:02:37 PM2/7/10
to

I've had many mysterious bugs solved by users on the Firebug newsgroup,
sometimes over months. I wish there was better integration between bug
reports and newgroups. SUMO seems to have this role for Firefox, but it
is surprisingly invisible to and seemingly separate from developers.

> venting/anger in bugs does not help anyone, and allowing it will not
> help us in any measurable or imaginary way.

This is not at all my experience, as either venter or ventee. Passion is
a bit like smoke: better to look at than breath but almost always a sign
of fire.

jjb

>
> -- Mike

Mike Connor

unread,
Feb 7, 2010, 3:10:26 PM2/7/10
to johnjbarton, dev-pl...@lists.mozilla.org

On 7-Feb-10, at 9:02 PM, johnjbarton wrote:
>
>> venting/anger in bugs does not help anyone, and allowing it will not
>> help us in any measurable or imaginary way.
>
> This is not at all my experience, as either venter or ventee.
> Passion is a bit like smoke: better to look at than breath but
> almost always a sign of fire.

Sure, and passion will continue to appear in bugs. But we don't need
dozens of passionate "me too" comments to know there's probably fire,
and we should encourage and feedback *in the proper forums* so we
don't turn the bug report into an unreadable mess.

-- Mike

Mike Connor

unread,
Feb 7, 2010, 3:06:09 PM2/7/10
to Zack Weinberg, dev-pl...@lists.mozilla.org, johnjbarton

On 7-Feb-10, at 8:53 PM, Zack Weinberg wrote:

> Mike Connor <mco...@mozilla.com> wrote:
>> On 7-Feb-10, at 8:29 PM, Zack Weinberg wrote:
>>> IMO a good start toward fixing this would be to change the Bugzilla
>>> etiquette guidelines so that under no circumstances short of actual
>>> spam is it acceptable to tell anyone to stop commenting on a bug.
>>
>> There's a middle ground between "reject all feedback" and "will
>> accept endless advocacy comments."
>

> From our perspective, yes.
>
> From the perspective of each user who has gone to the trouble of
> creating a bugzilla account so they can tell us that (insert your
> favorite old bug here) is a problem for them too, only to be told
> to go away, there is no difference.
>
> Because of that, I think we need to permit, and possibly even respond
> positively to, advocacy and venting in bugs EVEN THOUGH it is
> unhelpful to the small group of people who use bugzilla as a task
> queue.

Help me out here... how does this help the situation? Is your
expectation that people who do not feel immediately rejected will
eventually lead to more triage/QA/devs from the community? Will it
lead to better/earlier bug reports on important regressions?

This might be brutal math, but we're talking about trading off core
developer time (incredibly high value, and all too finite) against the
feelings of some larger set of unknown people who choose Bugzilla
instead of newsgroups or mailing lists to vent their feelings. If
you're talking about taking up _more_ time for the latter group, what
are we getting beyond warm fuzzies?

Again, I strongly believe we can be more positive about how we
redirect that energy, without making Bugzilla into a free-fire zone,
and achieve better outcomes for everyone involved. I share your
desire to make sure we have better interactions, but your solution is
the wrong path, IMO.

> Being ignored is arguably even worse than being told to go away. We
> should be taking efforts up to and including hiring more support staff
> in order to ensure that no one is ignored. Support scales more easily
> than devs.

Support is hard to scale too, and not something we've been 100%
successful with to date.

-- Mike

Mike Connor

unread,
Feb 7, 2010, 3:17:47 PM2/7/10
to Zack Weinberg, dev-pl...@lists.mozilla.org, johnjbarton

Phillip Jones

unread,
Feb 7, 2010, 3:21:14 PM2/7/10
to

I've been told to go away more than once and not just on the comments
about removing Profile manager from FireFox (SeaMonkey).

There should be a way to vote *For* or *against* a bug.

The previous bugs I have commented on often have been reasonable
suggestion for or on RFE's.

I've had a Bugzilla account since the early days of Mozilla. and have
posted for Mozilla, FireFox, and even ThunderBird bugs and even
submitted bugs. In fact I just go through submitting a Bug on SeaMonkey
2.0.2 on a email/newsgroup problem.

Zack Weinberg

unread,
Feb 7, 2010, 3:22:21 PM2/7/10
to Mike Connor, Boris Zbarsky, dev-pl...@lists.mozilla.org
Mike Connor <mco...@mozilla.com> wrote:
> > There's a huge difference between "This bug is about A, not B;
> > please (file a new bug for B | discuss B in bug NNNNN, which is
> > about that)" and "Stop complaining about this bug, it'll get fixed
> > when it gets fixed". The latter is what I think we should stop
> > doing, *even though*
> > it means more nagging from bugmail.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=18574 is the
> pathological end state for that type of behaviour.
>
> Ultimately, nagging in bugs just makes bugs harder to read, and
> spams everyone following the bug with unhelpful comments. If it
> doesn't actually make a difference to fixing the bugs, why are the
> negatives worth it? Again, there's more constructive ways to educate
> people, but I've seen dozens, if not hundreds, of bugs, get to 100+
> comments, of which far less than half advance the fix for the bug in
> any way. Unthrottling that type of comment would exacerbate the
> situation, and I really am struggling to find a net positive
> outcome...

You're still thinking about it from a developer's perspective. Yes,
bugs like 18574 are very hard to read through. Yes, that demotivates
developers to the point where sometimes they don't get fixed for longer
than they would have been if they had not attracted as much advocacy
from users not capable of fixing the bug themselves.

Neither of those things is as important as the demotivating effect on
external users of being told to go away. Being told to go away *once*
from bugzilla is (I reiterate) enough to give a user the *permanent*
impression that we don't want to hear from them about anything, ever.
And then they tell their friends, who then won't try in the first
place. And no, you cannot expect newcomers to hear the difference
between "don't comment on this bug" and "don't talk to us again ever."

I don't think 18754 is a great example, actually, since that seems to
come down to a policy decision that MNG was not a format we wanted to
support. Thus, the bug *is* an appropriate place to argue about
whether that was a correct policy decision. Some would say bugzilla
is not suited for such arguments, but actually I think it's better than
the available alternatives -- mailing list threads peter out and get
lost in the past; forums are harder to find things in, and have all
the same lack-of-threading-or-filtering problems that bugzilla does.

https://bugzilla.mozilla.org/show_bug.cgi?id=915 is a better example;
it is clear that we should fix it, but it's damn hard and has been
punted for many releases now. It does attract a fair bit of advocacy.
It has technical discussion buried in there which is hard to find. And
I *still* think we should allow users to harangue us as much as they
want about it. In the bug.

zw

Zack Weinberg

unread,
Feb 7, 2010, 3:26:08 PM2/7/10
to Mike Connor, dev-pl...@lists.mozilla.org, johnjbarton
Mike Connor <mco...@mozilla.com> wrote:

>
> On 7-Feb-10, at 9:02 PM, johnjbarton wrote:
> >

> >> venting/anger in bugs does not help anyone, and allowing it will
> >> not help us in any measurable or imaginary way.
> >
> > This is not at all my experience, as either venter or ventee.
> > Passion is a bit like smoke: better to look at than breath but
> > almost always a sign of fire.
>

> Sure, and passion will continue to appear in bugs. But we don't
> need dozens of passionate "me too" comments to know there's probably
> fire, and we should encourage and feedback *in the proper forums* so
> we don't turn the bug report into an unreadable mess.

I disagree even with the assertion that bugzilla is not the proper
venue for advocacy. As I mentioned in passing in the message I just
sent, mailing list threads get lost too easily, and all the forums we
have have all the same lack-of-threading-and-filtering problems that
bugzilla does, plus it is much harder to find things in them at all,
plus fewer developers bother to read them.

zw

Phillip Jones

unread,
Feb 7, 2010, 3:39:13 PM2/7/10
to
Mike Connor wrote:
>
-------------------snip-------------------

> There's a middle ground between "reject all feedback" and "will accept
> endless advocacy comments." I agree we don't always handle negative
> responses well, but newsgroups and other avenues other than our task
> management system exist to handle feedback and discussion. Continued
> venting/anger in bugs does not help anyone, and allowing it will not
> help us in any measurable or imaginary way.
>
> -- Mike

But there is a difference between *Spamming* and venting - or rather
being a proponent of keeping a feature developers are just dying to kill.

A Spammer post stuff such as best deal for Pills or for x rated sites
or get rich schemes and so on.

Message has been deleted

johnjbarton

unread,
Feb 7, 2010, 3:47:23 PM2/7/10
to

We don't have "the proper forums", that's exactly the problem. It is not
so hard for experienced users of bugzilla to point to a bug from a
newsgroup. But the reverse takes way too much time.

Pairing bugs with an advocacy/support/feedback/discussion venue would
address many problems with bugzilla and community relations. Maybe a
newsgroup-like entry point or staging area for bugzilla. It would bring
more connection between sumo and developers. It could enable support
people to screen and route bug reports. It would provide an alternative
outlet for commentary, allowing bug reports to be dull, plodding steps
toward resolution.

jjb


>
> -- Mike

Bernd

unread,
Feb 7, 2010, 3:51:12 PM2/7/10
to Zack Weinberg, dev-pl...@lists.mozilla.org
Am 07.02.2010 21:26, schrieb Zack Weinberg:
> I disagree even with the assertion that bugzilla is not the proper
> venue for advocacy.
I am not sure that you will find a lot of developers who share this
point of view. I disagree with your point, which I hope is singular, as
it would make bugzilla less useful for me than it is now.

Speaking of bug 915, regardless how many advocacy you permit 11.5 years
tell a very clear message that this bug is not our priority. So whats
the point of letting people vent their anger, it will certainly not
convert the bug into a actionable item.

What would make bugzilla attractive for users is if bugs are solved in a
timely manner, anything else makes a short fuzzy feeling but does not
help on a long scale. So I judge your proposal from a point of view if
it makes bug resolution faster or slower. It seems to me that it slows
us down, so it doesn't look attractive.

Bernd

Zack Weinberg

unread,
Feb 7, 2010, 3:51:59 PM2/7/10
to Mike Connor, dev-pl...@lists.mozilla.org, johnjbarton
Mike Connor <mco...@mozilla.com> wrote:
> On 7-Feb-10, at 8:53 PM, Zack Weinberg wrote:
> >
> > Because of that, I think we need to permit, and possibly even
> > respond positively to, advocacy and venting in bugs EVEN THOUGH it
> > is unhelpful to the small group of people who use bugzilla as a task
> > queue.
>
> Help me out here... how does this help the situation? Is your
> expectation that people who do not feel immediately rejected will
> eventually lead to more triage/QA/devs from the community? Will it
> lead to better/earlier bug reports on important regressions?

Yes and yes. Not only from the people who do not themselves
immediately feel rejected, but from people who (as it is now) feel that
it is not worth their time to bother trying to tell us about problems,
because they have *heard* about incidents where someone was blown off
in bugzilla.

This is a long-term benefit - we're probably looking at at least five
years to overcome the existing impression of being unfriendly and
unwilling to change our minds. But it will eventually pay off in
spades.

I'm not just talking out my ass here - take a look at the Dreamwidth
project, which forked the Livejournal source code and servers with the
specific aim of being friendlier to both end-users and potential
developers than Livejournal itself had been. They've been around for
less than a year (IIRC) and they've already attracted a tremendous
amount of development talent, mostly from their own userbase.

> This might be brutal math, but we're talking about trading off core
> developer time (incredibly high value, and all too finite) against
> the feelings of some larger set of unknown people who choose
> Bugzilla instead of newsgroups or mailing lists to vent their
> feelings. If you're talking about taking up _more_ time for the
> latter group, what are we getting beyond warm fuzzies?

Warm fuzzies are undervalued - the easiest way for us to attract more
community developers is to give the impression that working on Mozilla
code is fun and you get to work with really great people. Which it is,
and you do, but the first impression differs.

But more to the point, I don't think this has to take up more time for
core developers. It would have taken less time to write comments 288
and 304 on bug 915 if the text that amounts to "go away" had been
omitted, and of course it takes even less time to post nothing at all.
(Those are the bottom-most two comments that contain "go away"
content. I don't want to pick on David in particular.)

The positive response that every first-time commenter should get,
which also accomplishes a gentle redirection toward mailing lists
and/or other ways that a first bug-reporter could be helpful, can come
from support staff.

(If there's not already a way to be automatically forwarded the first N
comments posted by every new Bugzilla user, can we get one?)

> Again, I strongly believe we can be more positive about how we
> redirect that energy, without making Bugzilla into a free-fire zone,
> and achieve better outcomes for everyone involved. I share your
> desire to make sure we have better interactions, but your solution
> is the wrong path, IMO.

I think this might be getting at the fundamental disagreement here.
For me, and for practically everyone I know, being redirected at all is
stop energy. Sure, it can be done more or less politely, but it's
still stop energy. And it is particularly severe when it comes as a
response to a bugzilla comment, because it is an enormous pain in the
ass to make a comment on bugzilla in the first place. People who come
first to bugzilla rather than, say, the support forum, have invested
more in their comments and may expect that they're more likely to get a
constructive response from there. This is why rewarding that
investment with "go away" is so very bad.

> Support is hard to scale too, and not something we've been 100%
> successful with to date.

I don't know the track record here, but it seems to me that first-line
"make sure every report gets some kind of response" support should not
be hard to hire for.

(FYI, I've now hit my personal "posting too much on one thread on one
day" limit and will not respond further till tomorrow.)

zw

L. David Baron

unread,
Feb 7, 2010, 3:59:23 PM2/7/10
to dev-pl...@lists.mozilla.org
On Sunday 2010-02-07 21:17 +0100, Mike Connor wrote:
> Help me out here... how does this help the situation? Is your
> expectation that people who do not feel immediately rejected will
> eventually lead to more triage/QA/devs from the community? Will it
> lead to better/earlier bug reports on important regressions?

It could lead to better feelings for Mozilla from Web developers,
which in turn could lead to better Web developer support for
Gecko-based browsers and more interest in the Web platform features
we're developing.

Web developers may be different from end users in that there's a
higher portion technically-enough inclined to comment in Bugzilla
and those who do may be the ones more likely to have influence over
others.

-David

--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/

Mike Connor

unread,
Feb 7, 2010, 4:12:42 PM2/7/10
to Zack Weinberg, dev-pl...@lists.mozilla.org, johnjbarton

On 7-Feb-10, at 9:51 PM, Zack Weinberg wrote:

> Mike Connor <mco...@mozilla.com> wrote:
>> On 7-Feb-10, at 8:53 PM, Zack Weinberg wrote:
>>>
>>> Because of that, I think we need to permit, and possibly even
>>> respond positively to, advocacy and venting in bugs EVEN THOUGH it
>>> is unhelpful to the small group of people who use bugzilla as a task
>>> queue.
>>

>> Help me out here... how does this help the situation? Is your
>> expectation that people who do not feel immediately rejected will
>> eventually lead to more triage/QA/devs from the community? Will it
>> lead to better/earlier bug reports on important regressions?
>

> Yes and yes. Not only from the people who do not themselves
> immediately feel rejected, but from people who (as it is now) feel
> that
> it is not worth their time to bother trying to tell us about problems,
> because they have *heard* about incidents where someone was blown off
> in bugzilla.
>
> This is a long-term benefit - we're probably looking at at least five
> years to overcome the existing impression of being unfriendly and
> unwilling to change our minds. But it will eventually pay off in
> spades.

If we're blowing them off, how often is it because we're going in a
direction that they don't agree with? Short of changing our decision-
making, how will tolerating advocacy change their desire to get
involved? (i.e. if I don't accept your view of where X should go, but
I'm nicer about it, will that substantially alter your desire to get
involved? I think that's unlikely.)

People are attracted to projects where people have similar and
overlapping priorities. I think it's a conceptual leap that engaging
with people with different priorities/beliefs/focus areas will lead to
them becoming effective contributors that help us go in the direction
we feel we need to go. People who are well-aligned with our goals are
rarely blown off, while those who are trying to push us in a different
direction are (all too often). I strongly doubt that playing nicer/
letting people vent/etc will actually yield a larger community of
strongly-aligned triage/QA/dev people.

>> This might be brutal math, but we're talking about trading off core
>> developer time (incredibly high value, and all too finite) against
>> the feelings of some larger set of unknown people who choose
>> Bugzilla instead of newsgroups or mailing lists to vent their
>> feelings. If you're talking about taking up _more_ time for the
>> latter group, what are we getting beyond warm fuzzies?
>
> Warm fuzzies are undervalued - the easiest way for us to attract more
> community developers is to give the impression that working on Mozilla
> code is fun and you get to work with really great people. Which it
> is,
> and you do, but the first impression differs.

The tricky part is noted above. Warm fuzzies happen when people do
awesome stuff that helps us. Giving people warm fuzzies for being
angry and posting multi-paragraph rants doesn't seem like it
encourages the right behaviour. I wish it were, but I've tried to be
gentler in the past, and in the long term (approaching seven years)
it's been a net loss of my time. I can't think of _one_ significant
contributor who started off with angry ranting in a bug, despite many
attempts to respond generously to feedback.

> But more to the point, I don't think this has to take up more time for
> core developers. It would have taken less time to write comments 288
> and 304 on bug 915 if the text that amounts to "go away" had been
> omitted, and of course it takes even less time to post nothing at all.
> (Those are the bottom-most two comments that contain "go away"
> content. I don't want to pick on David in particular.)

Of course, you're counting the time to write the comments, and not the
time of everyone who read the bugmail to see if it was relevant.

> The positive response that every first-time commenter should get,
> which also accomplishes a gentle redirection toward mailing lists
> and/or other ways that a first bug-reporter could be helpful, can come
> from support staff.

It can come from anyone, and despite my often-snarky mood, I generally
try to be positive and encouraging even as I ask people to vent
elsewhere.

>> Again, I strongly believe we can be more positive about how we
>> redirect that energy, without making Bugzilla into a free-fire zone,
>> and achieve better outcomes for everyone involved. I share your
>> desire to make sure we have better interactions, but your solution
>> is the wrong path, IMO.
>
> I think this might be getting at the fundamental disagreement here.
> For me, and for practically everyone I know, being redirected at all
> is
> stop energy. Sure, it can be done more or less politely, but it's
> still stop energy. And it is particularly severe when it comes as a
> response to a bugzilla comment, because it is an enormous pain in the
> ass to make a comment on bugzilla in the first place. People who come
> first to bugzilla rather than, say, the support forum, have invested
> more in their comments and may expect that they're more likely to
> get a
> constructive response from there. This is why rewarding that
> investment with "go away" is so very bad.

We should really figure out how to deflect people earlier. "If you
want to submit feedback, place X or Y or Z is better and more
productive." Lots of developers will engage in mailing lists,
especially if people aren't just calling us names.

>> Support is hard to scale too, and not something we've been 100%
>> successful with to date.
>
> I don't know the track record here, but it seems to me that first-line
> "make sure every report gets some kind of response" support should not
> be hard to hire for.

Clearly you've never done customer support full time. :) It's a high-
turnover industry with pretty brutal burnout rates. (I worked at IBM,
for great managers, and the average time before someone quit was 14
months.)

-- Mike

Mike Connor

unread,
Feb 7, 2010, 4:21:28 PM2/7/10
to L. David Baron, dev-pl...@lists.mozilla.org

On 7-Feb-10, at 9:59 PM, L. David Baron wrote:

> On Sunday 2010-02-07 21:17 +0100, Mike Connor wrote:

>> Help me out here... how does this help the situation? Is your
>> expectation that people who do not feel immediately rejected will
>> eventually lead to more triage/QA/devs from the community? Will it
>> lead to better/earlier bug reports on important regressions?
>

> It could lead to better feelings for Mozilla from Web developers,
> which in turn could lead to better Web developer support for
> Gecko-based browsers and more interest in the Web platform features
> we're developing.
>
> Web developers may be different from end users in that there's a
> higher portion technically-enough inclined to comment in Bugzilla
> and those who do may be the ones more likely to have influence over
> others.

That's a different problem than the typical advocacy commenter. I do
wholly agree that engaging with Web developers in a positive and
encouraging way is critical. That said, I really doubt openly
tolerating and even encouraging advocacy comments in Bugzilla will
give us a great outcome.

Perhaps the key is to highlight and make positive examples out of web
developers who do awesome stuff? (Bob filed bug XXXXXX and gave us a
great testcase, and we were able to fix it for the alpha coming out
next week.) If we want to encourage a set of useful and positive
behaviours, let's reward those behaviours (in the form of both prompt
bug fixes and followup recognition). Reporting stuff that's bad,
testing and dogfooding against alphas so we get early feedback... if
we can execute on _those_ aspects of our engagement with developers, I
think that gets us miles and miles farther than simply letting people
bitch in bugs.

How many bugs, with testcases from the community, do we have unfixed
in bugzilla? Without looking, I'm sure the answer is "too many."
Changing that number seems like the best possible way to get the
outcomes you and I both want.

-- Mike

johnjbarton

unread,
Feb 7, 2010, 5:11:59 PM2/7/10
to
On 2/7/2010 1:12 PM, Mike Connor wrote:
>
...

> People are attracted to projects where people have similar and
> overlapping priorities. I think it's a conceptual leap that engaging
> with people with different priorities/beliefs/focus areas will lead to
> them becoming effective contributors that help us go in the direction we
> feel we need to go. People who are well-aligned with our goals are
> rarely blown off, while those who are trying to push us in a different
> direction are (all too often). I strongly doubt that playing
> nicer/letting people vent/etc will actually yield a larger community of
> strongly-aligned triage/QA/dev people.

Please consider some less extreme cases. Perhaps 180 degree misaligned
folks are not worth talking to, fine ignore them. But people who have
(or believe they have ?) overlapping priorities get lame treatment in my
experience (not however from mconnor in my experience). By now I would
not report a Firefox bug unless I thought Firebug users needed it fixed.
The cost/benefit is too high.

jjb

Boris Zbarsky

unread,
Feb 7, 2010, 6:31:54 PM2/7/10
to
On 2/7/10 3:46 PM, Mulder wrote:
> Maybe the way Mozilla works needs to change.

You mean blow off our existing volunteer contributors and future ones in
favor of people who are working full-time on the project? That seems
like a fundamentally bad idea (not that I'm biased by having been such a
volunteer contributor in the past or anything ;) ).

> In any case, it can't hurt to ask them; the worst they can say is 'No'.

As far as I can tell, we _have_ been asking. There's been hiring going
on continuously, and we have looked for Mac programmers, and the upshot
is that good people are not nearly as easy to find as you make them out
to be.

> I get my data from having to support users running 10.4, 10.5, and
> 10.6 in a corporate environment.

Data on what? Firefox performance?

> For those on 10.6, they gain nothing by running in 64-bit mode, as our own internal test prove time and
> time again.

You've done that on the 32-bit and 64-bit builds of Firefox? I'd like
to see your data. I pointed you to mine.

> Sorry, but I have to rely on what I see and what others who are
> smarter than me report for their experience.

<shrug>. I reported what our measurements show for our codebase. For
the specific case of Firefox on OS 10.6, 64-bit is a significant speedup.

> I disagree (see above). Once you add 32-bit plugins and Input Managers
> into the mix (many, many people use them) you lose any minor
> performance benefit you may have gained.

I know a fair number of non-technical and somewhat-technical Mac users
(several dozen just in my extended family), and none run an Input
Manager of any sort. 32-bit plug-ins will matter on the first page you
hit which contains an instance of that plug-in, but not on initial
startup, unless your homepage contains such (and the default homepage
does not).

So for most people I actually know who run OS X the performance benefit
would be very much there (the exceptions being those who change their
homepage to something with a plug-in instance on it).

Of course this is all anecdotes, not data. I'd welcome data here,
including whatever data you can actually share from your deployment.

>>> The only exception is a very narrow subset
>>> of all users that use resource-intensive applications such as those
>>> for motion graphics, RAW image processing, and even film editing, that
>>> are designed to get a performance boost from it.
>>
>> Citation needed.
>

> Programmers at Apple told me this themselves.

Well, as a _general_ rule this is more or less true in the sense that
most apps don't get a huge speedup, if any. The thing is, a web browser
is in fact a resource-intensive application that does graphics, image
processing, video compositing, etc. The point is, since we're talking
about a specific program, Firefox, all that matters for this discussion
is how Firefox performance is affected by being compiled for 64-bit.
Did you read Josh's blog post with the numbers?

> Since I'm not a programmer and they are, I must rely on what they say as being
> truthful until I have some indication that it's not.

<shrug>. Josh and I are programmers. I wonder why you're assuming that
we're not being truthful about the 64-bit Firefox performance numbers.

> Not true. Mozilla may not have stated this assumption, but it's
> clearly there; otherwise there would be no reason at this point to
> drop support after 3.7 ships.

The reason to drop support is that keeping support for 10.4
significantly complicates supporting 10.5 and especially 10.6 well.
Period. That's why it's being discussed. If it were easy to support
all three at once we wouldn't be having this discussion at all.

In case it's not clear to you, trunk builds right this second do NOT
support 10.4. Making them support it again would involve making several
changes which make the 10.6 user experience worse, as well as preventing
other future changes that make the 10.6 user experience better and make
the code less complicated and less prone to security problems.

So it's not like we're talking about a magic moment when we just declare
that 10.4 is not supported any more for no reason at all. There are
good technical reasons to not support it. The question is whether there
are other good technical or social reasons that haven't been mentioned
yet for keeping support.

> Since this is the first time I've ever heard of this conversation in
> the five years I've been using Firefox, I can only guess that it
> wasn't publicized very well, if at all, the last time.

The previous conversations happened right in this newsgroup/list; first
in November 2008, then again in April/May 2009. They were publicized
just as much as this time, if not more (blogged about, etc). What's
different about this time that you heard about it, exactly?
Computerworld happened to pick it up? It picked it up in April 2009 as
well:

http://www.computerworld.com.au/article/300899/mozilla_might_drop_firefox_support_mac_os_x_10_4_tiger_/

(hey, and it's the same computerworld writer too). So did The Register:

http://www.theregister.co.uk/2009/04/28/firefox_mac_support/

and ITworld:

http://www.itworld.com/software/67030/mozilla-might-drop-firefox-support-mac-os-x-104-tiger

I really can't help it if you decided to pay attention this this time
but not before... Or is it that some other news outlet that you happen
to read picked it up this time from computerworld but not the previous
two times? Not much we can do here; the news folks write about whatever
the heck they want to write about, and "we might likely drop support"
apparently doesn't count as news. E-mailing all our users is not really
the right thing to do in this sort of circumstance circumstance either.

>> Josh asked for "input". That's not necessarily the same thing as "user
>> input"; he's looking for input from users, extension developers,
>> whatever. But "I use 10.4 and it would suck for me" is not really
>> input; we _know_ there are people in that position.
>

> If you're going to try to parse words to mean only what you like,
> you're not going to win friends or influence people. "Input" means all
> all sources, be it users, developers, etc.

Yes, that's what I said.

> If you limit yourselves to
> listening only to those people who already think like you do, then
> you're ignoring the users that are affected by the arbitrary and
> capricious decisions.

We know there are users affected. Some of them negatively, some
positively. No one is saying this change will be great for all users,
and clearly the users for whom it's bad will be unhappy. But it will be
good for more users than it's bad for. The question is how much the one
group will benefit, how much the other group will lose, and what the
acceptable tradeoff there is. Information on those topics is very much
welcome. Just saying "there are some users for whom this will suck"
doesn't add much. There always are, for any change that's made.

> If you anger your users, you won't have enough
> of them to keep your business model and will cease to exist.

This cuts both ways. If we anger our 10.6 users, they might go away.
If we anger out 10.4 users, they might go away. We have more 10.6 users
than 10.4 users, and in a year will have even more of the former (if all
goes right) and fewer of the latter (pretty much no matter what). If we
have to pick one or the other to anger, the 10.4 users are the obvious
choice. Unless you have some information about why they're more special
than the 10.6 users?

Your main argument seems to be that we can somehow avoid angering either
group. That's not seeming feasible at the moment, but if you have a
magic way of making that happen, do tell.

> You're reading what I say, but you've already decided what you're
> going to do, regardless of what anyone says to object, or how many.

That's not the case at all. What matters is not how many people object
(clearly in the limit there are about 1.3 million likely objectors
here), but what the objections are. So far they're all things that have
already been considered when making the decision, which obviously means
they're not likely to change it.

> it's about respecting your users enough to listen and take what they say
> seriously.

Realistically, no user is ever going to say "dropping support for my
platform is OK by me". We don't expect them to. The question, again,
is whether the good of these users outweighs the good of other, more
numerous, users.

> I'd say Mozilla needs to rethink this plan.

What exactly is your proposal that accomplishes these goals:

1) Does not regress performance and stability on 10.6 (quite a number
of the crashes involved are in the Apple libraries we end up having
to use if we have a single binary that runs on both 10.4 and 10.6,
as I undertand).
2) Does not drop 10.4 support.
3) Does not complicate and slow down security updates for 10.5 and
10.6 users.
4) Does not make it significantly more difficult to implement
10.6-only features (like out-of-process plug-ins and tabs).

If you have a specific proposal here, I'd love to hear it, and I bet
Josh would too. If you're just saying "I don't like your plan, come up
with something else", then sorry, you're out of luck. We've tried to do
just that, for over a year now, and this is the best plan we've come up
with so far.

So far the one proposal I've heard from you is "hire more people and
make it work somehow", which we really have looked into already. Hasn't
panned out so far.

-Boris

Robert Strong

unread,
Feb 7, 2010, 6:43:56 PM2/7/10
to dev-pl...@lists.mozilla.org
On 2/7/2010 12:10 PM, Mike Connor wrote:
>
> On 7-Feb-10, at 9:02 PM, johnjbarton wrote:
>>
>>> venting/anger in bugs does not help anyone, and allowing it will not
>>> help us in any measurable or imaginary way.
>>
>> This is not at all my experience, as either venter or ventee. Passion
>> is a bit like smoke: better to look at than breath but almost always
>> a sign of fire.
>
> Sure, and passion will continue to appear in bugs. But we don't need
> dozens of passionate "me too" comments to know there's probably fire,
> and we should encourage and feedback *in the proper forums* so we
> don't turn the bug report into an unreadable mess.
I agree strongly with mconnor on this subject. If there really is a need
for a place for some subset of people to make "me too" comments or to
vent then I think a new tool specifically for this purpose would be a
good thing. Off the top of my head a "discuss this" link to a forum for
those people that want to vent would be better than allowing or as has
been suggested promoting overloading of the bug tracking / task
management system for purposes other than bug tracking / task management.

Robert

Boris Zbarsky

unread,
Feb 7, 2010, 7:05:41 PM2/7/10
to
On 2/7/10 6:31 PM, Boris Zbarsky wrote:
> The previous conversations happened right in this newsgroup/list; first
> in November 2008, then again in April/May 2009.

Softpedia reported on it at the time too:

http://news.softpedia.com/news/Firefox-Dropping-Mac-OS-X-10-4-Support-110557.shtml

-Boris

Message has been deleted

Phillip Jones

unread,
Feb 7, 2010, 11:44:49 PM2/7/10
to
Boris Zbarsky wrote:
-------------------snip-------------------

>>
>> Programmers at Apple told me this themselves.

And people from MS have said That MS word doesn't gain anything by 64
Bit as well.
PowerPoint is helped the most and Excel marginally.


>
> Well, as a _general_ rule this is more or less true in the sense that
> most apps don't get a huge speedup, if any. The thing is, a web browser
> is in fact a resource-intensive application that does graphics, image
> processing, video compositing, etc. The point is, since we're talking
> about a specific program, Firefox, all that matters for this discussion
> is how Firefox performance is affected by being compiled for 64-bit.
> Did you read Josh's blog post with the numbers?

-------------------snip-------------------

> -Boris

Rob Arnold

unread,
Feb 8, 2010, 12:09:47 AM2/8/10
to dev-pl...@lists.mozilla.org
On Sun, Feb 7, 2010 at 11:44 PM, Phillip Jones <pjo...@kimbanet.com> wrote:

> Boris Zbarsky wrote:
> -------------------snip-------------------
>
>
>
>>> Programmers at Apple told me this themselves.
>>>
>>
> And people from MS have said That MS word doesn't gain anything by 64 Bit
> as well.
> PowerPoint is helped the most and Excel marginally.
>

That's curious given that the next version of Office will have 64 bit native
applications (you can download the preview and try it out). The shift to
x86-64 is happening and Firefox must at least provide 64 versions. Microsoft
is definitely pushing this: Window Server 2008 R2 doesn't have a 32 bit
version, they sell the 32 bit and 64 bit versions of Windows Vista/7 in the
same box, and perhaps most importantly for this discussion Internet Explorer
8 comes in 32bit and 64 bit versions and 64 bit version is the default on 64
bit machines. We probably take the same performance hit on Windows 64 bit as
we do on OSX 64 from loading the 32 bit libraries, but since we don't
produce official 64 bit builds (I think we are close but it's not as much of
a priority) I don't think anyone has measured this.

-Rob

Boris Zbarsky

unread,
Feb 8, 2010, 12:20:56 AM2/8/10
to
On 2/7/10 11:44 PM, Phillip Jones wrote:
> And people from MS have said That MS word doesn't gain anything by 64
> Bit as well.
> PowerPoint is helped the most and Excel marginally.

I fail to see the relevance of any of this to Firefox.

-Boris

Shawn Wilsher

unread,
Feb 8, 2010, 12:30:43 AM2/8/10
to dev-pl...@lists.mozilla.org
On 2/7/2010 11:02 AM, johnjbarton wrote:
>> I'm sorry you had that experience -- no one should be laughing at
>> anyone trying to give good feedback.
>
> But it is common nevertheless. And 'ignored' is even more common.
Really John, you've been laughed at? Where did this happen since this
should really not be happening. As a community, we need to address the
instance that happened, and make sure the person who did so knows it was
uncalled for.

Cheers,

Shawn

Boris Zbarsky

unread,
Feb 8, 2010, 12:33:16 AM2/8/10
to
On 2/7/10 11:04 PM, Mulder wrote:
> No, you don't need to blow off volunteers, but if you have the ability
> to hire some full-time programmers who are very talented, it would
> help you by taking a significant load off the volunteers

Sure. But if these programmers are not willing to work with the
existing community, then they aren't very useful.

> Have you tried approaching Glenn Reid (he wrote major portions of
> Illustrator, before the CS series started, along with iMove 1.0 from
> scratch. Before that he wrote Adobe TouchType for NeXTSTEP, again from
> scratch. He's the author of several books on PostScript programming.
> Or how about Henry McGilton, who worked with Glenn at Right Brain
> Software? They're both very talented, and very smart.

I'll pass the names on to the recruiting folks.

> Yes, on Firefox performance. I have to test every version of Firefox
> on every version of Mac OS X (10.4, 10.5, and 10.6) with all the
> software we run at the company, before it gets approved to be
> installed. And that includes PowerPC systems where applicable. It's
> very time-consuming.

OK.

>> You've done that on the 32-bit and 64-bit builds of Firefox? I'd like
>> to see your data. I pointed you to mine.
>

> Yes, I've done it on 32- and 64-bit versions of Firefox.

Have you? Where did you get your 64-bit Mac Firefox build from?

> Unfortunately, I don't keep logs of data for these tests; only the
> results I need to see to show me whether or not a particular build
> works well on our systems with our current software, so I can't give
> you something I don't have.

Sad, but understandable.

> It might be for your test conditions, but since I answer an awful lot
> of questions regarding 10.6 in the Apple Discussions forums, everyone
> I've dealt with complains that either Firefox crashes in 64-bit mode,
> isn't compatible with their Firefox add-ons, or runs more slowly than
> a non-64 bit version.

I have to ask... where are these people getting their Firefox 64-bit
builds? Are they doing their own compiling?

> Or those sites that insist they must use Flash or some other plugin on
> their own home page or even every page (I'm looking at you, Adobe.).

Irrelevant to startup performance unless it's the homepage, as I said.

> So, plugins (especially Flash) are a huge problem and cause a larger
> performance hit

Yes, but generally irrelevant to startup performance.

"Performance" is a very multidimensional metric. I was very specific
about the sorts of performance I was talking about. Please don't
pretend to misunderstand and bring in non-sequiturs about other kinds of
performance issues. I know they exist. You know they exist. They're
not relevant to this discussion.

>> <shrug>. Josh and I are programmers. I wonder why you're assuming that
>> we're not being truthful about the 64-bit Firefox performance numbers.
>

> I'm not suggesting you're not being truthful. All I'm saying is that
> Apple's engineers know an awful lot that others don't because they
> know exactly how their OS works and have the code to look at, whereas
> the rest of us can only speculate or make educated guesses, if you're
> a programmer.

They know an awful lot that others don't about _our_ codebase and how it
performs? Possible, sure. It's not that likely they know more than we
do, really, unless they've actually gone and measured.

> If it were my decision, I'd build separate binaries for 10.4 (one
> PowerPC and the other Intel; not Universal binaries), and another one
> for 10.5 and 10.6. That way you could keep all three versions of Mac
> OS X supported without having to compromise performance for any of
> them.
>
> I have no idea how difficult in practice this would actually be or
> even if it would cost extra.

It would certainly cost extra (in people, primarily, though also
hardware usage, testing matrix size, user confusion about what version
to download, etc). I'll let someone more familiar with that end of
things chime in on how much extra if desired.

> I do know that Apple is able to do it with Safari

Since they know exactly what the user has OS-wise, they have no issue
with the user confusion problem, for one thing.

> so aside from their billions in cash to pay for anything
> they want, I can only presume Mozilla could do it, too.

That's a big aside. ;)

> I don't think any group of users should be "special", but I am
> suggesting that Mozilla could do more to get a higher adoption rate of
> 3.6 on 10.4.

That's the first time I heard you mention that, actualy.

> For example, if add-on developers would keep up in making
> their add-ons compatible with the newest version, that would make a
> different.

I have no idea what you're trying to say here.

> But even on much faster PowerPC systems running at
> 1.42 Mhz or faster, Firefox is as slow as molasses in launching, while
> Safari is much faster

Interesting. On my Intel Mac, Firefox launches faster than Safari (time
to "can type in url bar", not time to showing the window frame).

In any case, if you want a full treatise on startup performance you want
to talk to taras, or joelr, or dietrich. They can tell you all about
it. I'm not going to write an essay on it here

-Boris

timeless

unread,
Feb 8, 2010, 2:19:02 AM2/8/10
to Rob Arnold, dev-pl...@lists.mozilla.org
On Mon, Feb 8, 2010 at 7:09 AM, Rob Arnold <tel...@gmail.com> wrote:
> We probably take the same performance hit on Windows 64 bit as
> we do on OSX 64 from loading the 32 bit libraries, but since we don't
> produce official 64 bit builds (I think we are close but it's not as much of
> a priority) I don't think anyone has measured this.

We actually take a security hit atm on w7, the 64bit libraries are all
signed, whereas for reasons I cannot figure out the 32bit stubs which
we get as a 32bit process (which just chain to the 64bit libraries)
aren't all signed.

This has resulted in one of my patches waiting for Microsoft to get
back to me :(..

I know, I shouldn't get involved. Mozilla graciously provided me with
10.5 for my Mac G5 when I complained that they dropped 10.3 the last
time around.

Nickolay Ponomarev

unread,
Feb 8, 2010, 4:17:06 AM2/8/10
to dev-pl...@lists.mozilla.org

If you allow people from "outside" to post at all, they will post in
inappropriate places, no matter what
http://bugzilla.mozilla.org/page.cgi?id=etiquette.html says.

I think ultimately it's bugzilla's job to save developer's time, given
people not familiar with the etiquette and people deliberately not following
it.

For example it could allow trusted people (say, with editbugs) hide comments
or make summaries of long-winded comments. It could help fight bugspam by
giving people who don't mind the extra mails (call it a comment triage team)
a chance to "downvote" a new comment by a community member without a good
track of record before it gets sent to everybody.

In my opinion, moving in that direction would be a better investment of time
compared to implementing more ways to redirect people to different tools /
mailing lists.

Nickolay

Robert Strong

unread,
Feb 8, 2010, 4:35:50 AM2/8/10
to dev-pl...@lists.mozilla.org
On 2/8/2010 1:17 AM, Nickolay Ponomarev wrote:
> On Mon, Feb 8, 2010 at 2:43 AM, Robert Strong<rst...@mozilla.com> wrote:
>
>
>> On 2/7/2010 12:10 PM, Mike Connor wrote:
>>
>>
>>> On 7-Feb-10, at 9:02 PM, johnjbarton wrote:
>>>
>>>
>>>> venting/anger in bugs does not help anyone, and allowing it will not
>>>>
>>>>> help us in any measurable or imaginary way.
>>>>>
>>>>>
>>>> This is not at all my experience, as either venter or ventee. Passion is
>>>> a bit like smoke: better to look at than breath but almost always a sign of
>>>> fire.
>>>>
>>>>
>>> Sure, and passion will continue to appear in bugs. But we don't need
>>> dozens of passionate "me too" comments to know there's probably fire, and we
>>> should encourage and feedback *in the proper forums* so we don't turn the
>>> bug report into an unreadable mess.
>>>
>>>
>> I agree strongly with mconnor on this subject. If there really is a need
>> for a place for some subset of people to make "me too" comments or to vent
>> then I think a new tool specifically for this purpose would be a good thing.
>> Off the top of my head a "discuss this" link to a forum for those people
>> that want to vent would be better than allowing or as has been suggested
>> promoting overloading of the bug tracking / task management system for
>> purposes other than bug tracking / task management.
>>
>>
> If you allow people from "outside" to post at all, they will post in
> inappropriate places, no matter what
> http://bugzilla.mozilla.org/page.cgi?id=etiquette.html says.
>
I am more than fine with people commenting in bugs especially when the
comment actually helps move the bug forward. The main trouble with this
is that there are a subset of people that believe the way to get a bug
fixed is by ranting / venting, "me too's", etc. which IMO a waste of
time the vast majority of time. I am not looking for perfection by any
means and think it is foolish as well as expensive to make perfection as
a goal. I fully accept that some people will never follow the rules and
think a simple mechanism is sufficient to solve the majority of cases of
people needing a place to vent, etc.

> I think ultimately it's bugzilla's job to save developer's time, given
> people not familiar with the etiquette and people deliberately not following
> it.
>
> For example it could allow trusted people (say, with editbugs) hide comments
> or make summaries of long-winded comments. It could help fight bugspam by
> giving people who don't mind the extra mails (call it a comment triage team)
> a chance to "downvote" a new comment by a community member without a good
> track of record before it gets sent to everybody.
>
> In my opinion, moving in that direction would be a better investment of time
> compared to implementing more ways to redirect people to different tools /
> mailing lists.
>

My point is that *if* there is a need for a place for people to post
vents / rants, "me toos", etc. then we shouldn't just change / overload
the purpose of bugzilla to accommodate this need and instead develop a
solution for that need. Though I think the solution you have suggested
is over-engineered I am not entirely against it. I trust that anyone
that owned the solution for users to vent / rant, etc. to make the
decision that makes the most sense.

Robert

Jesse Ruderman

unread,
Feb 8, 2010, 5:07:27 AM2/8/10
to Robert Strong, dev-pl...@lists.mozilla.org
Would it make sense to move all advocacy comments out of the bug
stream, not just the ranty ones? I'm thinking of comments like

* This should block 1.9.2 because...
* This is a 1.9.2 blocker because...
* This is currently topcrash #3 for Firefox 3.5.5.
* This gets in the way of fuzzing.
* This could make startup 5% faster on Mac.
* This test is orange so often that philor has memorized the bug number.

Phillip Jones

unread,
Feb 8, 2010, 9:10:38 AM2/8/10
to

They are only doing so, as Apple is going to 64 bit or nothing. Older
program will have to be run in Rosetta mode. Plus the are planing to
bring back Macros and VBA on 2010.
But for word processing they say 64 bit is a waste of time. Its only
with Graphics and some math calculations That 64 bit does any good.

Plus Adobe is having problems with creating PDF of 64 Bit Mac.
Evidently on Mac's version of 64 bit application that have to run 32 bit
have to be told to run 32 bit. Whereas on PC its automatic. if you have
64bit system installed it simply shifts to use 32 bit when needed.

Phillip Jones

unread,
Feb 8, 2010, 9:18:09 AM2/8/10
to
it was an add on to a previous comment made about apple in the thread.
technical the thread the comment was made about portions of it were
off topic.

All I have to say about this particular thread as its set in stone any
way. Go ahead and do it. when I need to use a Browser only If I still
happen to be on this machine I'll just got to OmniWeb, Safari, iCab,
Opera. of course you'll end up losing a loyal Mozilla product user
since the day it was introduced. But hey that don't matter.

Mulder

unread,
Feb 8, 2010, 9:54:07 AM2/8/10
to
On Feb 7, 11:33 pm, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 2/7/10 11:04 PM, Mulder wrote:
>
> > No, you don't need to blow off volunteers, but if you have the ability
> > to hire some full-time programmers who are very talented, it would
> > help you by taking a significant load off the volunteers
>
> Sure.  But if these programmers are not willing to work with the
> existing community, then they aren't very useful.
>
> > Have you tried approaching Glenn Reid (he wrote major portions of
> > Illustrator, before the CS series started, along with iMovie 1.0 from

> > scratch. Before that he wrote Adobe TouchType for NeXTSTEP, again from
> > scratch. He's the author of several books on PostScript programming.
> > Or how about Henry McGilton, who worked with Glenn at Right Brain
> > Software? They're both very talented, and very smart.
>
> I'll pass the names on to the recruiting folks.
>
> > Yes, on Firefox performance. I have to test every version of Firefox
> > on every version of Mac OS X (10.4, 10.5, and 10.6) with all the
> > software we run at the company, before it gets approved to be
> > installed. And that includes PowerPC systems where applicable. It's
> > very time-consuming.
>
> OK.
>
> >> You've done that on the 32-bit and 64-bit builds of Firefox?  I'd like
> >> to see your data.  I pointed you to mine.
>
> > Yes, I've done it on 32- and 64-bit versions of Firefox.
>
> Have you?  Where did you get your 64-bit Mac Firefox build from?

Sorry, I meant to say on Mac OS X 10.6 running in 64-bit mode.


>
> > Unfortunately, I don't keep logs of data for these tests; only the
> > results I need to see to show me whether or not a particular build
> > works well on our systems with our current software, so I can't give
> > you something I don't have.
>
> Sad, but understandable.
>
> > It might be for your test conditions, but since I answer an awful lot
> > of questions regarding 10.6 in the Apple Discussions forums, everyone
> > I've dealt with complains that either Firefox crashes in 64-bit mode,
> > isn't compatible with their Firefox add-ons, or runs more slowly than
> > a non-64 bit version.
>
> I have to ask... where are these people getting their Firefox 64-bit
> builds?  Are they doing their own compiling?

Again, my typo. I meant Mac OS X 10.6 in 64-bit mode.

Yes they do. You might be surprised at the number of people who
download Safari and discover they can't install it because it's the
wrong version for their system, or if they can install it, it won't
run because it's incompatible with their version of Mac OS X. Apple
has to compile three sets of code to cover 10.4, 10.5, and 10.6, since
the available feature set for each is different. The potential for
confusion is huge with regards to Safari, yet most people don't make
the wrong choice, so I can only guess most Firefox users wouldn't make
that mistake, either.


>
> > so aside from their billions in cash to pay for anything
> > they want, I can only presume Mozilla could do it, too.
>
> That's a big aside.  ;)
>
> > I don't think any group of users should be "special", but I am
> > suggesting that Mozilla could do more to get a higher adoption rate of
> > 3.6 on 10.4.
>
> That's the first time I heard you mention that, actualy.
>
> > For example, if add-on developers would keep up in making
> > their add-ons compatible with the newest version, that would make a

> > difference.
This is the most common reason for people not to upgrade their Firefox
installation. At the same time, it seems the more add-ons used, the
slower Firefox becomes, which defeats the purpose of using add-ons at
all.


>
> I have no idea what you're trying to say here.

I'm saying that there are performance issues, since much older systems
running NeXTSTEP (the precursor to Mac OS X) were able to launch
complex programs such as a web browser faster than current systems
today using much faster processors. Even so, Firefox is very slow to
launch on PowerPC systems.

Boris Zbarsky

unread,
Feb 8, 2010, 10:12:00 AM2/8/10
to
On 2/8/10 9:54 AM, Mulder wrote:
> Sorry, I meant to say on Mac OS X 10.6 running in 64-bit mode.

You were _very_ specifically replying to my saying that 64-bit Firefox
is faster on 64-bit 10.6 than 32-bit Firefox is. You claimed to have
tested both and not seen a difference.

If you're just saying that 32-bit Firefox running on 64-bit 10.6 is no
faste, and possibly slower, than 32-bit Firefox running on 32-bit 10.6,
then sure, of course it is. That's the whole reason for having a 64-bit
Firefox on 64-bit 10.6!

> Yes they do. You might be surprised at the number of people who
> download Safari

On Mac? I sure would, since it comes preinstalled and gets pushed out
as an automated update when a new version ships, including for major
version bumps! I have yet to meet a Mac user who has gone and manually
downloaded Safari.

> The potential for
> confusion is huge with regards to Safari, yet most people don't make
> the wrong choice

Most people don't make the choice at all; they get it through the update
channel.

Who is actually manually downloading it and why? I can see cutting-edge
folks doing it in the small gap between official release and being on
the update channel; those would tend to be more advanced users than
average and less likely to make mistakes about this sort of thing, I
would bet.

The Firefox situation, however, is pretty diferent. New Firefox users
_have_ to download it, no matter whether they even know what their OS X
version is.

-Boris

Message has been deleted

Rob Arnold

unread,
Feb 8, 2010, 11:52:43 AM2/8/10
to mozilla.dev.planning group


I'm not sure that I would give Apple all the credit for this, especially
given the 64-bit-only server release. I have a feeling that Linux is more
likely to be the cause in the server market.


> Older program will have to be run in Rosetta mode. Plus the are planing to
> bring back Macros and VBA on 2010.
> But for word processing they say 64 bit is a waste of time. Its only with
> Graphics and some math calculations That 64 bit does any good.
>

I think Firefox (and other browsers) tend to do quite a bit of graphics and
math calculations on 64 bit. It's nice to know that SSE2 is always available
for instance.


>
> Plus Adobe is having problems with creating PDF of 64 Bit Mac. Evidently on
> Mac's version of 64 bit application that have to run 32 bit have to be told
> to run 32 bit. Whereas on PC its automatic. if you have 64bit system
> installed it simply shifts to use 32 bit when needed.


Adobe's problems with their port come from the fact that unlike Windows not
all the OS X APIs for 32 bit applications are available for 64 bit
applications. I am not an OS X developer so I do not know exactly which
libraries got dropped but I do know that Apple is quite aggressive in their
development of new APIs and retirement of old ones. Sometimes you can get
away with shipping different binaries but I think part of the problem here
is that the source would also need to significantly differ between the 10.4
and 10.5+ versions. This makes supporting both platforms much harder.

-Rob

Chris Forsythe

unread,
Feb 8, 2010, 12:22:37 PM2/8/10
to
On Feb 5, 9:34 pm, Phillip Jones <pjon...@kimbanet.com> wrote:
> Asa Dotzler wrote:
> > On 2/5/2010 3:18 PM, Mulder wrote:
> >> While Mozilla may think that dropping support for Mac OS X 10.4 is a
> >> good idea, you're dead wrong. There is no need to do this; it's a
> >> short-sighted plan to avoid supporting well over a million users who
> >> are still running 10.4 for various reasons;
>
> > And you think it will still be well over 1 million users a year from now?
>
> If the economy doesn't get better - yes.
>
> -------------------snip-------------------


Those people can still download the old version even when 10.4 support
is dropped right? Just because newer versions will come out that
doesn't mean the old version will just stop working the day after
support is dropped. You're arguing like this is the case.

Antonino Di Liberto

unread,
Feb 8, 2010, 12:23:31 PM2/8/10
to
> We are planning to make the decision to remove 10.4 support final and
> remove the code from the tree. If you have any strong objections
> please let us know now.

I'm not planning to pass from tiger to leopard in the next 12 months,
and, i suppose, as me many other users too; so i think you are wrong
to stop the support for mac os x tiger. This means that many users,
like me, will pass to opera or other...
To you the choice...

Chris Forsythe

unread,
Feb 8, 2010, 12:42:47 PM2/8/10
to
On Feb 4, 11:16 pm, Josh Aas <josh...@gmail.com> wrote:
> In September of 2009 we stopped supporting Mac OS X 10.4 ("Tiger") on
> mozilla-central but we left much of the code required to support that
> platform in the tree in case we wanted to reverse that decision. We
> have come to a point where we need to make a final decision and either
> restore 10.4 support or remove this (large) amount of 10.4 specific
> code.
>
> Here are usage numbers from 2010-01-25:
>
> ===========
> Firefox 3.5
> ===========
> 10.6 (Darwin 10.x): 1,497,221 (26%)
> 10.5 (Darwin 9.x): 2,855,842 (50%)
> 10.4 (Darwin 8.x): 1,379,770 (24%)
> All versions of Mac OS X: 5,732,833
>
> ===========
> Firefox 3.6
> ===========
> 10.6 (Darwin 10.x): 186,825 (59%)
> 10.5 (Darwin 9.x): 91,478 (29%)
> 10.4 (Darwin 8.x): 35,960 (12%)
> All versions of Mac OS X: 314,263
>
> Mac OS X 10.4 was released in April of 2005 and a lot has changed
> since then. We would like to take advantage of more modern
> technologies on Mac OS X and 10.4 support has been a hindrance. Where
> we can work around supporting 10.4, doing so consumes valuable time
> and effort. Neither Chrome nor Safari has to deal with this.
>
> The approximately 25% of our Mac OS X users still on 10.4 would
> continue to be supported by Firefox 3.6 until that product reaches end
> of service, which won't be until several months after the next major
> version of Firefox is delivered (built on Gecko 1.9.3) later this
> year. Past data shows that we do not lose appreciable market share
> when we stop supporting a Mac OS X version. We are often one of the
> last vendors to continue supporting older Mac OS X releases, and I
> suspect that by the time this becomes an issue Apple may themselves
> have stopped issuing security updates for Mac OS X 10.4.
>
> Adding 10.4 support back to mozilla-central would mean switching back
> to ATSUI from Core Text, switching back to gcc-4.0 from gcc-4.2, and
> doing a bit of porting work for code that has been added to the tree
> since we dropped support for 10.4. Other areas where 10.4 support
> consumes our time, makes our code more complex or error-prone, and/or
> limits our capabilities include complex text input (IME), out-of-
> process plugins, printing, native menus, and Core Animation.
> Furthermore, Apple's upcoming JavaPlugin2 will not support Mac OS X
> 10.4.

>
> We are planning to make the decision to remove 10.4 support final and
> remove the code from the tree. If you have any strong objections
> please let us know now.

Do you have a published policy on support for older os's? On Adium
when I was Project Manager, we had one:

http://trac.adium.im/wiki/SupportedOSPolicy

Overall it stopped all sorts of arguments like this. It fit into what
we believed we could support, and how long we really wanted to work on
older stuff.

Just a thought. Rather than run into this situation again when 10.5 is
the old and nasty and 10.7 is the nice and sexy, it might be worth
creating a policy now to address this now and in the future.

Old Man

unread,
Feb 8, 2010, 12:42:53 PM2/8/10
to
Don't know what to say about programmers in general these days, if
something is a year old, they want to kill support for it.

Let me put it this way, I have been supporting Macs since the early
90's and the fastest Macintosh I own is a 9600/350 with a 1Ghz G4
processor upgrade. I never supported the decision from Steve Jobs to
switch to the slower, troublesome, and less efficient BSD clone, OSX.
I still use OS 8.6 and you guys over at Mozilla stopped supporting
Classic around '02 or sometime around there, so I don't think this
decision hurts me any for I use Classilla( http://www.floodgap.com/software/classilla/
) for all my browsing needs on my Macintosh's. However, you guys need
to stop being big babies and get organized! Lay now a pre-set time
frame and life span for each major version, say 10 years support and
updates and STOP KILLING SUPPORT! I may not even use 10.4, but trust
me, I know how it feels to be left out in the cold software wise
simply because the developers felt their wasn't a big enough user
base. When the user base gets down to 1-2%, than think about cutting
support, but until then, SUPPORT YOUR PRODUCT!

Lazy developers.

timeless

unread,
Feb 8, 2010, 12:50:19 PM2/8/10
to Chris Forsythe, dev-pl...@lists.mozilla.org
On Mon, Feb 8, 2010 at 7:22 PM, Chris Forsythe <ch...@growl.info> wrote:
> Those people can still download the old version even when 10.4 support
> is dropped right? Just because newer versions will come out that
> doesn't mean the old version will just stop working the day after
> support is dropped. You're arguing like this is the case.

Roughly speaking the day we drop support for a product is the day it's
vulnerable to a security exploit, because there will probably be an
exploit which is fixed in the supported versions and thus published in
our repositories and applicable to the unsupported product.

The internet is not your kindergartner's sandbox, it's a warzone out
there, if you aren't using properly tuned equipment, you will probably
suffer. :(

FWIW, this is no different from what happens for any other browser
from any other vendor, it's the Internet, not us.

Boris Zbarsky

unread,
Feb 8, 2010, 12:56:39 PM2/8/10
to
On 2/8/10 12:23 PM, Antonino Di Liberto wrote:
> I'm not planning to pass from tiger to leopard in the next 12 months,

And tiger support isn't going to be dropped in the next 12 months. The
soonest I can see it being dropped given current plans is 14 months from
now.

> To you the choice...

Well, to us and to you, yes. ;)

-Boris

Asa Dotzler

unread,
Feb 8, 2010, 1:02:29 PM2/8/10
to
On 2/8/2010 9:42 AM, Chris Forsythe wrote:

> Do you have a published policy on support for older os's? On Adium
> when I was Project Manager, we had one:
>
> http://trac.adium.im/wiki/SupportedOSPolicy
>
> Overall it stopped all sorts of arguments like this. It fit into what
> we believed we could support, and how long we really wanted to work on
> older stuff.
>
> Just a thought. Rather than run into this situation again when 10.5 is
> the old and nasty and 10.7 is the nice and sexy, it might be worth
> creating a policy now to address this now and in the future.

I suspect that we don't always know until we start to approach it given
that OS versions aren't all equal in terms of changes to APIs and other
important characteristics. A hard and fast policy about a certain
number of versions or a certain date might mean un-supporting an OS
version before we actually need to.

Then again, it might be worth it if it gives certainty to people who
need it.

- A

Robert Strong

unread,
Feb 8, 2010, 1:10:06 PM2/8/10
to dev-pl...@lists.mozilla.org
I personally see these as part of bug / task management for the most part.

Asa Dotzler

unread,
Feb 8, 2010, 1:17:05 PM2/8/10
to
On 2/8/2010 9:42 AM, Old Man wrote:

> base. When the user base gets down to 1-2%, than think about cutting
> support, but until then, SUPPORT YOUR PRODUCT!
>
> Lazy developers.

Well, Firefox users on Mac OS X 10.4 account for approximately 1.6% of
all Firefox users this month. So, according to your rant here, now is
about the right time to think about cutting support.

In one year or so, when the actual impact would hit, my trending says
Firefox users on Mac OS X 10.4 will be less than 1% of all Firefox users.

So, now that you know a bit more about the situation, do you have any
additional suggestions?

- A

It is loading more messages.
0 new messages