Here are usage numbers from 2010-01-25:
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
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
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.
Since support for plugin1 has already been removed from trunk, this
means supporting 10.4 in 1.9.3 would *also* mean reintroducing it.
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.
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)
> 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.
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
> 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
I don't know why I tilt at windmills, it does no good. :-(
Historically, Mozilla (the community) has been pretty awesome about
filling the voids which Mozilla (the company) creates out of necessity.
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.
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...
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.
I've seen crazier things. :)
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.
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.
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.
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
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.
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
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
Over 80% of Macs, as reported here
are running 10.5 or 10.6 and those running 10.4 are dropping off at
about 10% per month.
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.
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
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" ?
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
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.
> Anthony Hughes (:ashughes)
> Jr QA Engineer, Mozilla QAE
> On 05/02/2010 12:51 PM, Phillip Jones wrote:
>> I don't know why I tilt at windmills, it does no good. :-(
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.
If the economy doesn't get better - yes.
> - A
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.
I think you should also take in account the Intel/PPC support.
It means that keeping 10.4, Mozilla have to test/support:
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.
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.
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.
> 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).
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
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.
(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
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?
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
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.
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.
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
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.
> 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.
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).
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.
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
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
> 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.
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
I'm sorry you had that experience -- no one should be laughing at
anyone trying to give good feedback.
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).
But it is common nevertheless. And 'ignored' is even more common.
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.
<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,
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.
> 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
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
> 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".
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.
> 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.
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.
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
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
> 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
> 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...
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
> -- Mike
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 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
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.
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.
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.
> 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.
> 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.
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
> -- Mike