ignorance or malice?
There are a number of blog posts out there, presumably based on the same Gregg Keizer article, that are claiming "Mozilla Won't Fix 80% of Firefox 3.0’s Bugs"
That claim is simply horseshit. We've already fixed over 11,000 bugs and features in Firefox 3 and now we're discussing how to handle the remaining 700 issues we wanted to get fixed for Firefox 3.
update While I do think that the the article's headline was over the top, I didn't mean this to come off as rude as it now reads to me. Reading a couple of the comments here I see that I wasn't setting a very good example with the tone of my post. Sorry about that, and sorry Gregg (if you're reading this) for those comments that I unintentionally inspired.
I wasn't actually reacting to Gregg's article so much as a few blog posts I read that referenced Gregg's article -- or even just the headline. The headline, which I think is wrong in several ways, got a lot of pickup and a number of people who know considerably less about Mozilla than Gregg got my ire up with their commentary.
reactions, thoughts, comments, etc.
I’m certain Mike Angelo of MozillaQuest would place the number closer to 95%.
Posted by: Minh Nguyễn | November 15, 2007 7:54 PM
Unfortunately this is what you get from vultures when using an open development process...
Posted by: Jeff Schiller | November 15, 2007 8:09 PM
Oh man - I forgot about MozillaQuest. What good times those were. :)
Posted by: Matt | November 15, 2007 8:40 PM
comment removed by Asa. please try to avoid personal attacks. I'll try to set a better example, but there's just no call for calling people names.
Posted by: monk.e.boy | November 16, 2007 5:01 AM
Asa, your server is sending ISO-8859-1, your pages however appear to be UTF-8.
You've get a meta tag specifying UTF-8, but every browser I can test in gives the server-sent value precedence.
Posted by: BtEO | November 16, 2007 6:35 AM
The browsers are right; the charset value in the Content-Type header has precedence. See http://www.w3.org/TR/html401/charset.html#h-5.2.2. http://www.w3.org/TR/xhtml1/#C_9 would be relevant if the pages included an XML declaration.
Posted by: Jesse Pelton | November 16, 2007 7:38 AM
Let's hope that the Browser proves everyone wrong and puts the rumours to bed, I for one, am looking forward to the latest incarnation.
Posted by: FF3 | November 16, 2007 9:34 AM
Shouldn't the percentage actually be a lot higher than 80%? Surely there are a lot more bugs out there unresolved than just the ones labeled as "blockers".
Please correct me if I'm misunderstanding this.
Posted by: n00b | November 16, 2007 11:03 AM
Heh, wait until you get a load of the garbage that is CNET:
http://blogs.cnet.com/8301-13505_1-9818903-16.html?part=rss&subj=news&tag=2547-1_3-0-5
Posted by: Omega X | November 16, 2007 12:43 PM
n00b: Amazingly, no, the actual number is around 77%. There are currently 37040 bugs open in the Firefox and Core products, and 37000/(37000+11000) =~ 77%
Of course, that's a completely useless metric to judge by.
However, there is one thing I'm concerned about, which is the number of regressions. There's around 600 in firefox and core, and over half of them aren't even blocking?. I know there's lots of things already on the plate and we want a release soon, but several hundred regressions, even very minor ones, seems like something that'll be quite noticeable in the final product.
Posted by: dolphinling | November 16, 2007 1:57 PM
v3.0 b1 hasn't been released yet and people are complaining about buggy code. Seems a bit strange really. Or are people desperate to diss Mozilla?
Posted by: Sneeb | November 16, 2007 1:57 PM
You should be more careful how you talk to and about people. I've noticed this about your posts before. You don't seem have concern for people's feelings. Someone can be wrong, so set them straight, but try to be a little more kind about it.
Posted by: Pricemuenster Mulholland | November 16, 2007 2:15 PM
Of course this leaves the question: "what absolute number of bugs, and what abssolute number of functional 'blockers' will be allowed in the final release of Firefox 3?". Ideally the numbers would be zero blockers, and a managable number of non-blocking bugs that can all be fixed within a month or two of final release as the first minor version update. 700 blocking bugs sounds very much like the non-blocking bugs that a lot of people quite seriously care about (I'm thinking full CSS2 compliance for instance) number in the thousands - how many are acceptable to move to public release?
Posted by: Pomax | November 16, 2007 4:43 PM
"We've already fixed over 11,000 bugs and features in Firefox 3" - that's the horseshit, you have CLOSED 11,000 bugs, absolute majority of them with "won't fix" or some similar resolution.
I understand the lack of time and resources, and I understand that less than ideal release is better than no release at all. Just stop lying to us.
Posted by: Alex | November 16, 2007 4:57 PM
Pomax, you're just wrong here and we have a public bug database and cvs repository that anyone can query to demonstrate that. We've actually closed tens of thousands of bugs with various resolutions and more than 11,000 with the Fixed resolution and code in CVS to back that up. You're free to query Bugzilla and Bonsai yourself, and next time I suggest you do before just makeing shit up.
- A
Posted by: Asa Dotzler | November 16, 2007 5:14 PM
Sounds like Vista. Microsoft was planning to deliver much more than they eventually did, but due to development problems they had to start axing features (remember WinFS?).
Development of Firefox 3.0 has been slower than expected, and now hundreds of bug fixes and enhancements that were deemed critical for 3.0 (and thus marked as blocking it) are getting carved out of the release.
You're bound to get some bad press for that.
Posted by: Ballmer's Chair | November 16, 2007 5:16 PM
Asa, you may want to regain your composure a bit, it seems like you misdirected your reply to Alex to me instead (but even then, it might be a good idea to work on delivery, it's just as easy to say "you're making up numbers, the bug database and cvs show over 11,000 marked 'fixed'" without having to resort to name calling.)
Posted by: Pomax | November 16, 2007 5:32 PM
Asa, come on mate, calm down! It's your personal blog, which is cool, but you're a respected figure within the Mozilla community!
Please don't lower yourself to the level of the trolls out there by swearing and getting worked up.
Posted by: Mr Lizard | November 16, 2007 7:24 PM
I'm always amazed how people will comments on these issues, without the slightest idea of what they're talking about. Every developer knows that their products contains bugs. The point is that you can never fix all bugs, so you have to make a coice. Will you delay the product trying to fix as many as you can, or will you postphone them to a later release. That is a completely normal development cycle, but Mozilla's open source development presents this to the whole world. Do you really think Explorer, Safari or Opera don't have any bugs on their plate ?
Gregg made a badly informed article, with a totally incorrect and sensational title. Now it seems that Mozilla will /on purpose/ refuse to fix 80% of its bugs. That's why Asa made that rude remark, and I agree totally with it.
I'm using the nightly 3.0 builds, and I can assure that it's a very stable and very fast release. One more month of regression testing (or so) will make it the best release every. There really should not be done much, just a few important things like the "cookie-monster" bug, and a few performance improvements. Beta 2 will provide the Breakpad reports that indicate which crashes are the most important to fix. We just have to stop trying to cram more new things inside, which is what the article really should have said. That's the reason why most of the 700 issues will not be fixed now, but inthe next releases.
Posted by: jhermans | November 17, 2007 3:37 AM
Sometimes, simple and direct is the best approach.
If you see "Mozilla Won't Fix 80% of Firefox 3s Bugs"
and you say
"That claim is simply horseshit."
Its all the pertinent information 99.9% of us need. If you know software,you know something about metrics, and you know its horsehit. If you don't know software, its all you need to know.
Posted by: Gary Johnson | November 17, 2007 10:33 AM
To all concerned,
Well as long as NoScript runs in whatever latest FF build, I feel secure. I know that NoScript as an extension is controversial, only for the paranoid, and the normal user should avoid this, fully familiar with the discussion, eh...but I personally would not touch a Mozilla type browser like FF or Flock without its protection in the background, it has saved my glorious behind too many times...as I realize also that it never will be brought in as a normal default feature (too much oposition from certain circles)....
polonus
Posted by: polonus | November 18, 2007 8:45 AM
The Times has a history of playing fast and loose with the facts. I don't blame Asa for being upset. Honstely I've called them far worst.
Posted by: Sean | November 18, 2007 9:38 PM
Here's an example:
https://bugzilla.mozilla.org/show_bug.cgi?id=78414
This "critical" bug, which now has 72 votes, describes plugins breaking keyboard shortcuts. It was filed ALMOST SEVEN YEARS AGO. As of today, its status is NEW and the target milestone is Future. Excuse me if I don't hold my breath. This is why many think Mozilla doesn't focus enough on bugfuxes.
Posted by: Josh | November 19, 2007 10:21 AM
Josh, there's nothing critical about that bug. It doesn't even count as a major bug. And it's not clear how to fix it without risking major incompatibilities with plugins. See comment 115.
And I can live with it. If you can't, then you might as well quit complaining and just get another browser, because there are always going to more important things to fix.
Posted by: VanillaMozilla | November 19, 2007 12:37 PM
Josh, the real work to fix that is taking place in bug 348279. But please make sure not to add comments to bug reports. Comments just get in the way.
Posted by: VanillaMozilla | November 19, 2007 12:43 PM
Josh, the real work to fix that is taking place in bug 348279. But please make sure not to add comments to bug reports. Comments just get in the way.
Posted by: VanillaMozilla | November 19, 2007 12:45 PM
I guess that bug is major enough to people who can't use a mouse, and to the 72 people who voted for it. Maybe we should all stop complaining and get another browser, right? Believe me: if there was another browser that sucked less, I would.
Meanwhile, trivial bugs such as the wrong background image in a dialog box[0] are fixed almost immediately. It's a lot easier to claim 11,000 bugfixes when you cherry-pick the trivial ones, eh?
As for 348279, here's the description:
Aaron Leventhal 2006-08-10 15:54:16 PST
Spunoff from bug 93149 and bug 78414.
We need to start moving forward on fixing those bugs
Gee, Aaron, you think?
[0] https://bugzilla.mozilla.org/show_bug.cgi?id=403238
Posted by: Josh | November 19, 2007 1:27 PM
OK, Josh, I get the point about the mouse. And your last link was funny. Come to think of it, I think I've made similar complaints, but without the humor.
Posted by: VanillaMozilla | November 20, 2007 6:33 AM
Josh,
Trivial bugs get fixed relatively quickly EXACTLY because they are trivial. If you can check in a file and change one line to fix a bug with little risk to anything else (or check in an image), that is going to get fixed long before rearchitecting a major component, which could impact areas all over a product and cause many OTHER regressions if not done correctly.
Welcome to software, mate.
Posted by: Al Billings | November 21, 2007 11:24 AM
Thanks for the welcome, Al, but you're about 30 years late. My argument is not that trivial bugs should go unfixed; it is that even serious, architecture-affecting bugs should be fixed within a reasonable time. If you believe that six years and counting is an acceptable time frame then I believe you're in the wrong profession.
Posted by: Josh | November 21, 2007 8:56 PM
It is acceptable if no one thinks it needs to be fixed enough to do the work. People vote with their feet (or, in this instance, their code). It hasn't been fixed because it hasn't been fixed. At the end of the day, someone decided to work on something else. Is there a meta point that was missed?
People complain that easy bugs are fixed instead of hard ones at times but it is obvious why this is the case. Did I somehow miss your meta point in all of this? You seemed to be unhappy that a trivial bug was fixed.
Posted by: Al Billings | November 22, 2007 2:03 PM